* Fixed the indentation of the sample code in docs/feature_pointing_device.md sample.
* Update docs/feature_pointing_device.md
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* Fix info about RGB LEDs on the bottom.
* Added RGB LEDs support
* Added RGB LEDs config options
* Added minila layout with RGB keys
* Create readme.md
* Update keyboards/ymdk/bface/keymaps/minila/keymap.c
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/ymdk/bface/keymaps/minila/keymap.c
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/ymdk/bface/keymaps/minila/keymap.c
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/ymdk/bface/keymaps/minila/readme.md
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/ymdk/bface/keymaps/minila/readme.md
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* initial commit for tsangan_hhkb community layout
* keymap.c done
* wrote readme
* move media keys; add shortcuts
* edit to reflect changes in keymap
* update readme with imgur link
* do the basic port for the WM1
* with much help from tzarc, get the addresses correct
* make the keymap more closely mirror what the board has
* Add QMK Configurator support
* update the readme
* get indicator leds working
* enable RGB underglow
* fix up rgb underglow
* add notes regarding existence of backlight
* Update keyboards/wolfmarkclub/wm1/readme.md
* Update keyboards/wolfmarkclub/wm1/rules.mk
* Update keyboards/wolfmarkclub/wm1/rules.mk
* Update keyboards/wolfmarkclub/wm1/rules.mk
* Update keyboards/wolfmarkclub/wm1/rules.mk
* Update keyboards/wolfmarkclub/wm1/config.h
* Update keyboards/wolfmarkclub/wm1/ld/wm1_f103.ld
* Update keyboards/wolfmarkclub/wm1/bootloader_defs.h
* Update keyboards/wolfmarkclub/wm1/config.h
* Update keyboards/wolfmarkclub/wm1/rules.mk
* Update keyboards/wolfmarkclub/wm1/wm1.c
* Update keyboards/wolfmarkclub/wm1/wm1.c
* Update keyboards/wolfmarkclub/wm1/rules.mk
* Update keyboards/wolfmarkclub/wm1/rules.mk
* Update keyboards/wolfmarkclub/wm1/readme.md
* Update keyboards/wolfmarkclub/wm1/rules.mk
* Update keyboards/wolfmarkclub/wm1/rules.mk
* Update keyboards/wolfmarkclub/wm1/rules.mk
* Update keyboards/wolfmarkclub/wm1/rules.mk
* update readme
* Add support for Ace of Spades
* Fix the F-row mappings
* Add the tkl_iso layout
* Put KC_PAUS back in place of top layer reset
* aholland909 personal keymap for Ace of Spades
* Address PR feedback and rename to aos/tkl
* Rename keyboard implementation filenames
* Remove unnecessary layers
* info.json for the configurator
* ARM split - Add uart half duplex transport support
* Fix for f103
* initial full duplex pass
* partially remove full duplex
* Correct speeds within driver docs
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Nick Brassel <nick@tzarc.org>
* newbs_flashing.md: place bootloader instructions before Toolbox intro
* Update docs/newbs_flashing.md
* More wordsmithing, point ARM users at Discord if all else fails
* Link Discord
The factory TMK firmware for the TADA68 supports backlight breathing,
so I was surprised when the BL_BRTG key I set up in the online QMK
configurator didn't work.
As far as I can tell, this was just a simple omission.
* CLI: Improve experience when running `qmk setup` on FreeBSD.
* Install the `avrdude` package as well.
* Switch to installing python packages w/ `--user` flag.
* Basic getting started sections for FreeBSD.
* Update `util/freebsd_install.sh` for root/non-root branches.
* Add ID to doc section.
Co-Authored-By: skullydazed <skullydazed@users.noreply.github.com>
* Add ID to another docs section.
Co-Authored-By: skullydazed <skullydazed@users.noreply.github.com>
* Use `; then` in script for consistency.
Co-Authored-By: skullydazed <skullydazed@users.noreply.github.com>
* Updated to use sudo in one shot if available.
* Apply suggestions from code review
Co-authored-by: Erovia <Erovia@users.noreply.github.com>
* Style fixes for latest version in master.
* Apply suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: skullydazed <skullydazed@users.noreply.github.com>
Co-authored-by: Erovia <Erovia@users.noreply.github.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Added Chimera Ortho keymap
* Cleaning up the rules
* Removing firmware sizes
* Modified URLs to point to new locations
* Remove _quantum functions from custom matrix.c code
* Fix 1<col instead of 1<<col typo in matrix_is_on()
* Make PREVENT_STUCK_MODIFIERS the default
* Removing the IS_COMMAND custom definition
* Adding info.json
* Adding config overrides
* Adjusting for the reformat
* removing backlight reference
* fixing some compile issues
* Fixing a matrix issue
* Update keyboards/chimera_ortho_plus/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/chimera_ortho_plus.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/chimera_ortho_plus.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/chimera_ortho_plus.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/chimera_ortho_plus.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/chimera_ortho_plus.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* lining up the matrix
* Update keyboards/chimera_ortho_plus/readme.md
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/chimera_ortho_plus/readme.md
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/chimera_ortho_plus/info.json
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/chimera_ortho_plus/chimera_ortho_plus.h
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/chimera_ortho_plus/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/chimera_ortho_plus/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* added git codes
* started git layer
* finished structure for git layer. MOD: replaced mouse with mod keys on right hand
* layout changing layer
* mod enter. default qwerty layer. removed mods on number layer
* workman layout. git log, show. blank enter and bsspace
* config layer. toggleable ctrl/alt for OS
* removed keymap comments
* strings and combos layers. sarcasm and ctrl_ctv. RGB configs
* reintroduced enter and bspace. delete backspace as a function. git push -u and checkout -b
* string macros
* OS specific home/end
* OS mac & win keys. N delete global backspace
* refactored backspace functions
* ctrl lctv macro
* base layer toggle fix
* whitespace
* BS + L for FF and chrome
* replaced 1 keycode with userspace
* added userspace config
* remove comments
* add another keycode with a variable
* moved all keymaps and codes to common file
* ctrl z mod
* removed ctrl z
* sipmlified OS functions
* moved is_win to keyboard level
* added mac alt tab
* added ctrl tab in mac + clean up variables in art.h
* tild string macro. added mac left/right + home/end
* mac ctrl backspace
* enum layers for default layout
* added ergodone keymap
* ergodone compiles
* clean up
* clean up
* removed obsolete OS_HOME/END
* removed var
* added ctrl nav to split75
* ergodone clean up + caps lock fix 75
* fix mac ctrl alt on right handside. added mac alt tab left right
* fix ergodone config override
* fixed alt left right not working on mac
* added OS ctr_alt
* mac ctrl del. fix tild
* simplified tild macro
* git stash apply
* send_string_remembering_lenght
* shifted strings print
* restored KC_BSPACE functionality
* moved KC_BSPC
* numpad layer on Fn
* media lights
* ergodone final clean up
* ergodone GIT AND MEDIA layers
* ergodone GIT LAYER switch
* default behaviour for all modified keys on BASE layer
* refactored logic for default keycodes
* ergodone final layers
* ctrl_cav for translation and ctrl_l fix
* toggleable layer with numpad
* comments
* numpad layer
* Update users/art/config.h
Co-authored-by: Joel Challis <git@zvecr.com>
* enable dynamic macros for split75
* git branch and develop/master
* removed esc from Nav
* ergodone: ctrl alt for shift layer
* macros and right alt for ergodone
* fix ergodone N_backspace not working on git layers
* mac language switch with alt+shift
* Update users/art/art.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update users/art/art.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update users/art/art.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/ergodone/keymaps/art/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update users/art/art.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* flashing leds to indicate current os
* using rshift on shifted layers
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add Via support to the YMD09
* Update keyboards/ymdk/ymd09/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/ymdk/ymd09/keymaps/via/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Candybar: VIA support for lefty and righty
* Update keyboards/candybar/lefty/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/candybar/righty/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/candybar/lefty/keymaps/via/keymap.c
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* add feature_leader_key.md translation
* update based on comment
* set link as lang dir
* update based on comment
* update based on comment
* update based on comment
* Add Via keymap for Contra
* Added Via-enabled keymap
* Changed VENDOR_ID from 0xFEED to 0x4354 (CT)
* Removed unnecessary RGB mappings
* PR changes
* Removed empty via/config.h
* Changed product ID from 0x6060 to 0x0001
* Add files needed to The Via support on Melody 96
* Remove manufacture name from product name
* replace blank key with Transparent keys
* Update keyboards/melody96/rules.mk
* Update keyboards/melody96/keymaps/via/keymap.c
* Change Product ID to "M" + 96
* Update keyboards/melody96/keymaps/via/rules.mk
* add LTO to via's local file
* Update keyboards/melody96/rules.mk
* more stoof
* readme update
* reverting keymap
* re-adding userspace
* new userspace needed
* no want 0 under thumb
* gettin fancier with my knob
* macro fix
* had pins for oled ver
* wait, these are the right pins
* reduntant line
* image fix
* get highest layer every day
* whoops
* correct rev name in json
* a few good catches
* what I had planned
* Replace custom RCTRL implementation with built-in LM
Caveat: sends LCtrl instead of RCtrl
* Enable VIA support in KBD6X keymap
* Disable LTO on ChibiOS boards
* Disable locking support and Magic keycodes for all keymaps
* Organize and annotate rules.mk and config.h files
* Enable Console for Melody96 keymap
* L_RANGE_KEYMAP → LAYERS_KEYMAP
* Revert "Replace custom RCTRL implementation with built-in LM"
This reverts commit 17d706a82d7e31b53cd84efeb9b2ddb9922a2368.
* Set DYNAMIC_KEYMAP_LAYER_COUNT to 3 in Doro67 and Wasdat keymaps
* Enable Bootmagic Lite for all VIA keymaps
* added koy layout to qmk on xd75 board
* added koy keymap for the atreus62 board
* reduced time for autoshift
* added documentation
* changed layer 7 to a tap toggle and adjusted mouse speed a little
* Update keyboards/xd75/keymaps/ScheiklP/koy_keys_on_quertz_de_latin1.h
* Update keyboards/xd75/keymaps/ScheiklP/koy_keys_on_quertz_de_latin1.h
* Update keyboards/xd75/keymaps/ScheiklP/koy_common.h
* Update keyboards/atreus62/keymaps/ScheiklP/koy_common.h
* Update keyboards/atreus62/keymaps/ScheiklP/koy_keys_on_quertz_de_latin1.h
* Update keyboards/atreus62/keymaps/ScheiklP/koy_keys_on_quertz_de_latin1.h
* changed keymap to lowercase name to conform with qmk guidelines
* Update keyboards/xd75/keymaps/scheiklp/rules.mk
remove unnecessary rules
* Update keyboards/atreus62/keymaps/scheiklp/rules.mk
remove unnecessary rules
* moved common files for koy layouts to the users folder and removed empty file
* Update keyboards/atreus62/keymaps/scheiklp/keymap.c
* Update keyboards/xd75/keymaps/scheiklp/readme.md
* Update keyboards/xd75/keymaps/scheiklp/readme.md
* Update keyboards/atreus62/keymaps/scheiklp/readme.md
* Update keyboards/atreus62/keymaps/scheiklp/readme.md
* [kle2jinfo] use min/max instead of if
This is a slight change.
Before, the key_skel would keep the invalid value for future keys.
I think this is what was actually intended.
* [kle2info] calculate x
x is the current_x * key_size + (key_size/2)
y is the current_y * key_size + (key_size/2)
no reason to track both
* Improve stock bootloader list
* Switch version numbers on USB64/128 bootloaders
* Unix line endings for PS2AVRGB bootloader
* Update PS2AVRGB bootloader to 1.0.1
* Also mention bootloader rule
* Didn't need to change the links
This commits add the SH_OS keycode, which works similarly to one shot
layers:
* while pressed, the keyboard is swapped
* if no keys were pressed while it was pressed, the next key press is
swapped
SH_OS also supports chaining with one shot layers:
OSL(x) + SH_OS + key interprets the key press on the oneshot layer.
The ONESHOT_TIMEOUT setting used by one shot keys and layers is also
used by oneshot swap hands. In the above chaining scenario the timeout
of the oneshot layer is reset when swap hands is activated.
Resolves#2682
* Allow 16 lighting layers
* Require #define RGBLIGHT_LAYERS_16 to enable 16 layers
* Override RGBLIGHT_MAX_LAYERS to set maximum number of lighting layers
* Enforce lower bound on RGBLIGHT_MAX_LAYERS
Co-Authored-By: Takeshi ISHII <2170248+mtei@users.noreply.github.com>
* Fix an error in the check for valid RGBLIGHT_MAX_LAYERS
* Don't use bitfield / PACKED, as it causes bloat
* Update documentation re: up to 32 lighting layers
* Run cformat
* Add note about increasing FW size in docs/config_options.md
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Remove no-longer-valid comment
* Add doc note that split sync will be slower
Co-authored-by: Takeshi ISHII <2170248+mtei@users.noreply.github.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Improve security by eliminating the use of well-known names.
* Add an additional $ so the shell expands $TMP1 and $TMP2
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* Added MACLOCK macro
Added my MACLOCK macro to my Atreus keymap.
* Updated comments & readme
Documented where in the layout I added the MACLOCK macro.
* Updated with my super16 version for my keypad
* Added my folder to super16
* Set max LED brightness to 50%
* Added custom keycodes for enter/shift+enter and copy/paste on one key
* Fixed the boot up layer color
* Renamed folder
* Revert changes to root super16 files
* Update keymap config.h and rules.mk files
* Restore deleted 15game keymap files
* Corrected the hold keycode for CCCV
* Removed unnecessary comments
* Update keyboards/1upkeyboards/super16/keymaps/nblyumberg/keymap.c
Co-Authored-By: ridingqwerty <george.g.koenig@gmail.com>
* Update keyboards/1upkeyboards/super16/keymaps/nblyumberg/config.h
Co-Authored-By: ridingqwerty <george.g.koenig@gmail.com>
* Update keyboards/1upkeyboards/super16/keymaps/nblyumberg/keymap.c
Co-Authored-By: ridingqwerty <george.g.koenig@gmail.com>
* Rewriting the layer color functionality
* Revisions
* Fixed the layer switching
* Fixed the default layer color problem
* Added a function suggested by Drashna but it won't compile
* Cleaned up the code for PR
* Removed unnecessary define for layer colors
Co-authored-by: ridingqwerty <george.g.koenig@gmail.com>
* Implement momentarily blink of lighting layers
* Refactor spidey3 userspace to use rgb layer blink
* Remove un-necessary line from example in documentation
* Revert "Refactor spidey3 userspace to use rgb layer blink"
This reverts commit 831649bb68.
* Adds a missing bit of documentation about lighting layer blink
* Update docs/feature_rgblight.md per suggestions
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update docs/feature_rgblight.md per suggestions
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update docs/feature_rgblight.md per suggestions
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* cformat, as suggested
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Invert UC_MOD/UC_RMOD direction when Shift is held
Also use MOD_MASK_SHIFT in process_rgb.c
* Allow audio to be played for UC_MOD, UC_RMOD keycodes as well
* Fix signedness bug in reverse input mode cycling
* Misc formatting in process_unicode_common.c
* Address clang-format issues
* Make decode_utf8 helper function file-local (static)
* [Keyboard] Added D48 keyboard.
* Updated README.
* Cleanups.
* Moved d48 to handwired/
* Added link to build process album.
* Coding conventions cleanups.
* Added DS1307 RTC!
* Minor cleanups.
* Apply suggestions from code review
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Minor refactoring.
* Readme fix.
* Moved leftover keymap-specific code from keyboard space into keymap.
* Added encoder button pins to extra matrix row.
* Updated README, updated pinout & cleaned up the glcdfont
* Apply suggestions from code review
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Update config.h
* Apply suggestions from code review
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Added default keymap. Refactored existing keymap.
* Update keyboards/handwired/d48/README.md
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Apply suggestions from code review
Co-Authored-By: Joel Challis <git@zvecr.com>
* Minor alignment fix.
* Update keyboards/handwired/d48/glcdfont_d48.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Changes as per PR.
* Apply suggestions from code review
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* initial user directory
* fix missing endif in vi mode
* fix includes per drashna and a few typos. I have not tested the userspace keymap, it is just there to help keep the user space and keymap in sync
* move babblepaste docs to md format
* clean up block quotes
* TIL clang-format - miles2go userspace
* Add TENKI keyboard
Add TENKI keyboard, default keymap and via keymap
* Minor Update Readme.md
Change description of hardware supported
* change layout name
change layout name from ortho_20 to ortho_5x4
* Fix invalid format in info.json
Fix invalid format in info.json
* Fix invalid format
* Fix formatting
Fix formatting tenki.h
* Fix formatting in keymap.c
Fix formatting in keymap.c
* Add new line at EOF info.json
Add new line at EOF
* Fix formatting
* Fix formatting
* Update rules.mk
Fix Formatting
* Initial
* update json, added basic oled config, updated matrix to correct rotary location
* disable oled by default
* Tuned oled for release
* Completed OLED function implementation
Correct spelling error in readme
* Fixed image in readme
* Should not be in this branch
* Incorporating recommended changes by zvecr
* Update keyboards/le_chiffre/info.json
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/le_chiffre/readme.md
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Keyboard: add treeadstone48
* rename layout defines
* Use of pragma once
* move common include code
* fixed info.json
* change keymap layout from kc to normal
* fix alpha revision keymap
* fixed info.json
* remove USE_Link_Time_Optimization
* Add keyboard firmware of treadstone32lite
* fixed by the review
* I used to set this to a per-keymap setting, so I'll undo it.
* Community layout support for KBD67 hotswap
* Community layout support for KBD67 rev1
* Community layout support for KBD67 rev2
* Move bcat's KBD67 hotswap layout to community
* New keymap layout for dztech/dz65rgb/keymaps
* New keymap layout for dztech/dz65rgb/keymaps
- Conding conventions fixes
* Fix typo in Leader Key table
* PR #8199 Feedback Commit #1
* Fixed data types and function names - Simplified accent macros by removing repetition - Added selection wrap macros - readme.md doc updated with changes
* PR #8199 second feedback commit - Clarified function names, variables names and comments
* Fix: accent output fix _grave <==> _circumflex
* dry fixes on led set_color with hsv and led blinking code blocks
* my new layout, draft one, untested.
* updated mapping to include more keys
* updated layout name to be more descriptive. Updated readme with more information.
* added more info to the readme and spellchecked it.
* Added the Json for the keyboard layout images and updated the readme to reflect this.
* Updated Image link
Updated Image link so that it links to the correct place
* updated copyright info to include MY name.
* Updated copyright attribuatation to include the author of the file I modified.
* added the backlighting key back to the adjust layer so that it is usable.
* updated the name of the keymap to match my github name.
* Mitor Tweaks
Updating Dvorak keymap to change location of Slash and Backslash
to positions more in line with my 12x5 and similar ortho layouts
* Fixed readme.md
Tidied up the readme and make some minor changes.
* Adding atreus config file
Adding a config file for my Atreus keyboard. This is to help with
the keychatter issues I've been having on my Atreus.
* Changes as requested per @zvecr
Added `#pragma once` to beginning of config.h file as requested
by @zvecr.
* Working on proto
* Start adding VIA support
* Apply suggestions from code review
Removed redundant comments and fixed typos
Co-Authored-By: Ryan <fauxpark@gmail.com>
Co-Authored-By: Joel Challis <git@zvecr.com>
* Delete useless config.h
As per code review
* Delete elongate.c
As per code review
* Updated readme.md
* Update keyboards/acheron/elongate/keymaps/default/keymap.c
As per code review
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Apply suggestions from code review
Removed RGB_MODE_TEST definition and substituted for RGB_M_T
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Apply suggestions from code review
Reverted changes to alice.h
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update info.json
* Update via/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Solve compiling issue for via keymap
* Add botmagic support and remoce console_enable
Co-Authored-By: Joel Challis <git@zvecr.com>
* Update keyboards/acheron/elongate/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/acheron/elongate/keymaps/via/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/acheron/elongate/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/acheron/elongate/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Gondolindrim <alvaro.augusto.volpato@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* Refactor to use mpaland/printf
* trim firmware size
* remove keymap changes
* run clang format
* Fixup after rebase
* fix up git-submodule command for printf
* Branch point for 2020 May 30 Breaking Change
* audio-configuration: template: audio_avr.c does NOT default to C6
not on its own, it needs a pin configured per define in config.h for audio to actually work
otherwise only parts of the code are included in the firmware, wasting space and possibly breaking builds because auf hitting the firmware-size limits
* audio-configuration: strip comment to bare essentials
Co-Authored-By: Ryan <fauxpark@gmail.com>
* revert future change
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Johannes <you@example.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: zvecr <git@zvecr.com>
* Added raw hid feature documentation page
* Update docs/feature_rawhid.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update docs/feature_rawhid.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update docs/feature_rawhid.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update docs/features.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* added feature_rawhid.md to _summary.md in docs
* fixed _summary.md order
* Update docs/feature_rawhid.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update feature_rawhid.md
Removed the useless bit about finding usage page and usage.
* Update feature_rawhid.md
* Update docs/feature_rawhid.md
Co-Authored-By: Nick Brassel <nick@tzarc.org>
* Update docs/feature_rawhid.md
Co-Authored-By: Nick Brassel <nick@tzarc.org>
* Update docs/feature_rawhid.md
Co-Authored-By: Nick Brassel <nick@tzarc.org>
* Update docs/feature_rawhid.md
Co-Authored-By: Nick Brassel <nick@tzarc.org>
* Remove teensy client, small origanization fixes
* Fixed merge conflicts
Removed features.md
Updated _summary.md with new format and added RAW HID entry under Software Features
* Added rawhid feature page
Messy is what you get when you don't do things right the first time
Co-authored-by: fauxpark <fauxpark@gmail.com>
Co-authored-by: Nick Brassel <nick@tzarc.org>
* add 'togglePin' conveniance function
for AVR and chibios
* drop outmost parantheses
Co-Authored-By: Konstantin Đorđević <vomindoraan@gmail.com>
* toggle pin on avrs
toggle a pin configured as output by writing the corresponding bit to the PIN register
Co-Authored-By: Takeshi ISHII <2170248+mtei@users.noreply.github.com>
* togglepin: add documentation for newly added function
* Update docs/internals_gpio_control.md
Co-Authored-By: Konstantin Đorđević <vomindoraan@gmail.com>
* on AVR: use PORTD to toggle the output
... since not all MCUs support toggling through writing to PIN
Co-Authored-By: Ryan <fauxpark@gmail.com>
Co-authored-by: Johannes <you@example.com>
Co-authored-by: Konstantin Đorđević <vomindoraan@gmail.com>
Co-authored-by: Takeshi ISHII <2170248+mtei@users.noreply.github.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* id80: Transpose matrix to use faster COL2ROW routines
Even the standard QMK matrix_scan() function can give about 2 times
higher scan rate (if compiled with optimizations enabled) if the COL2ROW
matrix layout is used instead of ROW2COL. Although the ID80 PCB is
wired using the ROW2COL matrix layout, it is possible to transpose the
matrix from the QMK standpoint, so that "columns" would correspond to
horizontal connections, and "rows" would correspond to (mostly) vertical
connections; in this case the matrix could be handled as if it had the
COL2ROW layout.
The matrix layout change makes the older VIA JSON layout definition
incompatible, but the corresponding JSON was not yet accepted to the VIA
repository, so it should still be safe to make this change.
* id80: Remove obsolete comments
* A few final edits to the keymap and readme.
* Update keyboards/xd75/keymaps/buzzlighter1/readme.md
Co-Authored-By: Joel Challis <git@zvecr.com>
* Update keyboards/xd75/keymaps/buzzlighter1/readme.md
Co-Authored-By: Joel Challis <git@zvecr.com>
* Update keyboards/xd75/keymaps/buzzlighter1/readme.md
Co-Authored-By: Joel Challis <git@zvecr.com>
* Update keyboards/xd75/keymaps/buzzlighter1/readme.md
Co-Authored-By: Joel Challis <git@zvecr.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* initial commit for TGR 910 CE
* got firmware working on the 910 CE
* add VIA support
* add iso and all layouts
* update information about resetting the board
* fixup default keymap to have a second layer
* fixup default keymap
* add VIA enabled keymap
* cleanups and adding community layout support
* add caps lock led support and backlight
* add qmk configurator support
* Update keyboards/tgr/910ce/info.json
* Adding all relevant files for the Funky40
This should add all proper files for the funky40 a keyboard I designed for myself, /u/TheFourthcow, a 40% ortholinear with split spacebar.
* Second attempt to add all relevant files for the funky40, includes all reccomended changes from my previous pull request
* Revised most files for Funky40 including reccomenations from my previous pull request
* further modifications made to default funky40 board, compiles on my side with no errors hopefully this one works!
* Update keyboards/funky40/readme.mk.mk
* Update keyboards/funky40/keymaps/default/readme.md.md
* Update keyboards/funky40/keymaps/default/keymap.c
* Update keyboards/funky40/keymaps/default/keymap.c
* Update keyboards/funky40/keymaps/default/keymap.c
* Update keyboards/funky40/config.h
* updating readmes and keymap
* final update to keymap and readmes should function correctly with updates requested
* made changes as requested by noroadsleft to config and readme
* mpstewart dz60 layout
* Remove macro aliases from keymap
* Remove macro aliases from keymap
* Update keyboards/dz60/keymaps/mpstewart/keymap.c
* Remove macro aliases from keymap
* use AG_TOGG instead of AG_SWAP
Also some commentary changes, and a change to one of the layout graphics
* Update and try to clarify the CLI installation on Linux
* Update commands, add note for Debian/Ubuntu
* Update docs/newbs_getting_started.md
Co-Authored-By: Joel Challis <git@zvecr.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* Add new keymap to vitamins_included, this has four layers. Updated config file to sync rgb between the two halves.
* Cleaned up and added documentation for the keymap
* Updated the keymaps and documentation.
* Update keyboards/vitamins_included/keymaps/vitavim/keymap.c
* Update keyboards/vitamins_included/keymaps/vitavim/keymap.c
* Update keyboards/vitamins_included/keymaps/vitavim/keymap.c
* Update keyboards/vitamins_included/keymaps/vitavim/config.h
* Update keyboards/vitamins_included/keymaps/vitavim/keymap.c
* Update keyboards/vitamins_included/keymaps/vitavim/keymap.c
* Update keyboards/vitamins_included/keymaps/vitavim/keymap.c
* Update keyboards/vitamins_included/keymaps/vitavim/keymap.c
* Update keyboards/vitamins_included/keymaps/vitavim/keymap.c
* Update keyboards/vitamins_included/keymaps/vitavim/keymap.c
* add feature_grave_esc.md translation
* update based on comment
* update based on comment
* update based on comment
* update based on comment
* update based on comment
* Move menu key on ergo boards to match staggered
* Unify 60_tsangan_hhkb and 60_ansi_split_bs_rshift
* Sync KBD67, Quefrency with community layouts
* Update ergo KLE images
* Update community layout KLE images
* Update KLE images/descriptions for remaining keebs
* Add 65 ANSI Blocker Split BS default layout
- Add new 65 ANSI Blocker Split BS layout as many 65 ANSI Blocker layouts also support split backspace
* Add 65 ANSI Blocker Tsangan default layout
- Add new 65 ANSI Blocker Tsangan layout as many 65 ANSI Blocker layouts also support a split backspace and a 7u bottom row configuration.
* Fix file names
* Fix 65_ansi_blocker_tsangan keymap
* Fix 65_ansi_blocker_split_bs alignment
* Fix readme name for 65_ansi_blocker_split_bs
* Change 65_ansi_blocker_tsangan to 2u backspace
* Change spaces in preview to NBSP
* Change more spaces in preview to NBSP (right-alt)
* Add VIA keymap
Also adds more backlight levels.
* Change wasdat code PID
* Alias LAYOUT_fullsize_iso to LAYOUT_all
* Change VIA layout macro to LAYOUT_all
Co-authored-by: Maarten Dekkers <maartenn2001@gmail.com>
* Remove more mouse keys settings missed in #8836
* Turn off more unwanted make options
* clang-format my userspace
* Reword ergo layout docs so Crkbd is canonical
* Add a basic readme to my userspace
* Tweak Crkbd readme wording and fix typos
* Enable SPLIT_USB_DETECT for Lily58 w/ Elite-C bug
* add rev2 and thus rev1 as well
* nitpicks :)
* buncha stuff
* back to one rev
* back to community layout with errors
* I see you've met my typo
* remove default48 kemap rules
* re-rework into 2 revs
* readme changes
* whitespace cleanup
* default folder
* rev1 be default
* Update default vitamins_included keymap
* Turned on NKRO support
* Added NKRO toggle key to keymap
* Cleaned up key map to be more up to date with current standards
* configured RGBLED_SPLIT
* Update to xealousbrown.
5-13ms Latency decrease, 4x scan rate improvement.
(CUSTOM_MATRIX = lite) is a really great feature!
* Updated Readme.md, added an extra speedhack.
* More optimizations
* Update keyboards/handwired/xealousbrown/rules.mk
* Update keyboards/handwired/xealousbrown/rules.mk
Evidently there is a polycarb variant with underglow LEDs. This change should support that without negatively impacting aluminum case variant which only has 2 RGB LEDs on top.
* Give Tsangan layout a real Fn2 layer
* Disable mouse keys to work around qmk#8323
I don't actually use this feature, so there's no reason for it to be
enabled anyway, and it seems to cause spurious wakeups on Windows.
* Adding Novem keyboard (macropad) and demo layout
* Making changes suggested during pull request
* Removing keyboards/novem/keymaps/default/config.h as suggested during the pull request
* Moving keyboard to the handwired folder and changing the build line from readme in order to reflect this new location
* Add revision 1 and revision 2 to ProjectKB Alice PCB
* Swap SLEEP LED to no
* Basic root rules.mk
* Apply suggestions from code review
* Update keyboards/projectkb/alice/rules.mk
Using just qmk setup <github_username> would fail w/ "Could not find repo github.com/<username>, whereas the repo is actually after another slash after the user name. Can consider changing code to add the default forked repo name if slash is not detected in the arg.
* add VIA enabled keymap with some layers taken out for space
* get a more sane VID and PID so we don't collide with the other BMC powered boards
* small cleanups
* Update keyboards/tgr/jane/keymaps/via/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* add tkl_ansi_tsangan LAYOUT
* add tkl_iso_tsangan LAYOUT
Co-authored-by: Ryan <fauxpark@gmail.com>
* porting the niu_mini to via
* Wrong values in mk
* Updating to unique Vendor ID and Product ID
* Addressing zvecr comments
* Addressing fauxpark comments
Co-Authored-By: Ryan <fauxpark@gmail.com>
Co-authored-by: Lauren Harris <lauren.y.harris@outlook.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add support for hardware and board initialisation overrides.
* qmk cformat.
* Add some documentation.
* Docs clarity.
* Make early_hardware_init_pre a no-op for now, until migrations occur.
* Doco update
* Make distinction between keyboard and ChibiOS board in docs
* Doc anchors.
* Update tmk_core/protocol/chibios/main.c
Co-Authored-By: Joel Challis <git@zvecr.com>
* Rework bootloader entry to be off by default, allow opting-in.
Co-authored-by: Joel Challis <git@zvecr.com>
* id80: New keyboard (IDOBAO ID80)
Add initial support for the IDOBAO ID80 keyboard.
Most source files were generated by the KBFirmware JSON to QMK Parser
(https://noroadsleft.github.io/kbf_qmk_converter/) based on the
ID80.json file provided by the keyboard vendor. The only change to
rules.mk was to set `COMMAND_ENABLE = no` to make the compiled firmware
fit into the available flash space.
* id80: Update default keymap to match stock
Update the Fn layer in the default keymap to match the stock firmware
which was actually flashed into the PCB.
* id80: Add Caps Lock indicator support
Although the KBFirmware JSON includes information about the MCU pins
used for keyboard indicator LEDs, the KBF to QMK converter does not
generate the required code automatically. Implement the LED handling
code, and at the same time switch from the older `led_set_kb` API to the
newer `led_update_kb`.
* id80: Remove placeholder functions
The provided skeletons for `matrix_scan_kb` and `process_record_kb` did
not do anything useful, so remove them.
* id80: Use Esc as the Bootmagic Lite activation key
The Esc key is not at the (0, 0) position in the ID80 matrix, therefore
setting `BOOTMAGIC_LITE_ROW` and `BOOTMAGIC_LITE_COLUMN` is required to
use the Esc key for Bootmagic Lite.
* id80: Update info.json
Replace info.json generated by the KBF to QMK converter with another
version generated using http://www.keyboard-layout-editor.com/ and the
KLE raw to QMK info.json converter (https://qmk.fm/converter/). The
updated info.json has the correct physical layout (the distance between
the function key row and the main block is actually 0.25U, but the
vendor-provided ID80.json had 0.5U there) and correct key labels (using
the stock layout instead of raw matrix locations and pin names).
* id80: Enable NKRO
The default keymap is updated to have NK_TOGG at Fn+N, like most other
keyboards which have NKRO enabled.
* id80: Use unique USB vendor/product ID
Having an unique USB vendor/product ID is required for VIA support.
The vendor ID value is the same as for the `idobo` (ID75) keyboard.
* id80: Fix right modifiers in the default keymap
For some reason the default keymap converted from the vendor-supplied
JSON had the right Shift, Alt and Ctrl keys mapped to the left side
modifier keycodes.
* id80: Remove empty row 6 (F0) from matrix
The matrix layout which was defined in the vendor-supplied ID80.json
file had 12 rows which corresponded to the left and right parts of the
6 physical rows. However, the row 6 of the matrix (connected to the F0
pin), which corresponded to the right part of the physical bottom row,
was completely empty (all 9 keys of the bottom row were placed in the
matrix row for the left part). Keeping this row in the matrix just
wastes resources; in particular, when the VIA support is enabled, having
a 9×12 matrix with 4 layers leaves only 122 bytes available for dynamic
macros, which is less than the recommended minimum of 128 bytes.
Removing the unused row reduces the matrix size to 9×11, which leaves
194 bytes of EEPROM space for dynamic macros.
* id80: Update row numbers in the LAYOUT macro
Update row numbers in the names of the LAYOUT macro parameters after
removing a row in the middle.
* id80: Set RGBLED_NUM to 20 to match the actual PCB
The vendor-supplied ID80.json file specified that the PCB should have
28 RGB LEDs in the chain. However, the actual PCB that was shipped
from AliExpress had 20 LEDs in the chain (16 underglow LEDs, and then 4
more LEDs on top of the PCB, to the right of the Enter key location).
Update RGBLED_NUM to match the actual PCB.
* Add support for Caps Lock LED
Currently ignores the fact that led_state is not synced between halves, so caps lock LED doesn't do anything if USB is plugged into right half
* Set initial backlight and RGB mode/values on blank EEPROM
* Set default VIA layout options
* Add backlight/RGB ifdefs
* Set bootloaders for each rev
* dipsw test on helix/rev2/sc/back:five_rows
* bug fix quantum/dip_switch.c
* test end. remove test code. Revert "dipsw test on helix/rev2/sc/back:five_rows"
This reverts commit 4b13ebb996.
* dipsw test on helix/rev2/sc/back:five_rows
* update quantum/dip_switch.c
* test end. remove test code. Revert "dipsw test on helix/rev2/sc/back:five_rows"
This reverts commit bf99ace095.
GCC 4.9.4 is no longer available on Gentoo (or Sabayon), which causes
problems when attempting to install on either of these platforms. Since
QMK is not particularly sensitive to its GCC version, modify the version
restriction to <9 so newer versions of GCC may be installed. Since the
toolchain for arm-none-eabi isn't currently installed as part of setup,
add that as well.
Additionally, drop the Python installation as part of the Gentoo
installation process. Python is a core system package on Gentoo and can
therefore be assumed to be present; in addition, the slot restriction of
3.5 which was present is also no longer available in Gentoo.
Finally, separate the gcc rebuild invocation of `emerge` from the new
packages that may need to be installed, and apply the `--noreplace` flag
to new packages so that they are not rebuilt if already present.
* Cannonkeys DB60 Keyboard
* WhitespacE
* Add ISO and make layer names more idiomatic
* backlight enable
* Remove big backslash from ISO
* Apply suggestions from code review
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update for correct matrix
* Apply suggestions from code review
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update chibios config files
* Complete VIA keymap
* Remove ugly hack comments
* Update keyboards/cannonkeys/db60/rules.mk
Co-Authored-By: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* Save progress
* Finished matrix and everything
* Apply suggestions from code review
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update DevastatingTKL
* Renames
* Add renamed files
* Update chibios files and VIA keymap for completion
* Some cleanup
* Apply suggestions from code review
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/cannonkeys/devastatingtkl/rules.mk
Co-Authored-By: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* quantum/debounce: Added sym_pk debounce algorithm
* Apply suggestions from code review
Co-Authored-By: Ryan <fauxpark@gmail.com>
* quantum/debounce/sym_pk: delete comments and rename functions following code review
* quantum/debounce/sym_pk: Modifications for code readability according to code review
* quantum/debounce/sym_pk: Modifications for code readability according to code review (2)
* quantum/debounce/sym_pk: code review: cleaner code
Co-Authored-By: Nick Brassel <nick@tzarc.org>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Added personal minivan keymap, and started work on splitish directory
* Merge branch 'splitish' of github.com:RSchneyer/qmk_firmware into splitish
Trying to undo attempted fix
Added splitish keyboard files, removed personal Minivan keymap
* Removed personal Minivan keymaps
* Fixed small issue in readme
* Added changes based on inital PR feedback
* forgot a semicolon
* Quick config.h file and default keymap update
@@ -6,25 +6,24 @@ The QMK CLI makes building and working with QMK keyboards easier. We have provid
### Requirements :id=requirements
The CLI requires Python 3.5 or greater. We try to keep the number of requirements small but you will also need to install the packages listed in [`requirements.txt`](https://github.com/qmk/qmk_firmware/blob/master/requirements.txt). These are installed automatically when you install the QMK CLI.
QMK requires Python 3.6 or greater. We try to keep the number of requirements small but you will also need to install the packages listed in [`requirements.txt`](https://github.com/qmk/qmk_firmware/blob/master/requirements.txt). These are installed automatically when you install the QMK CLI.
### Install Using Homebrew (macOS, some Linux) :id=install-using-homebrew
If you have installed [Homebrew](https://brew.sh) you can tap and install QMK:
```
brew tap qmk/qmk
brew install qmk
brew install qmk/qmk/qmk
export QMK_HOME='~/qmk_firmware' # Optional, set the location for `qmk_firmware`
qmk setup # This will clone `qmk/qmk_firmware` and optionally set up your build environment
```
### Install Using easy_install or pip :id=install-using-easy_install-or-pip
### Install Using pip :id=install-using-easy_install-or-pip
If your system is not listed above you can install QMK manually. First ensure that you have python 3.5 (or later) installed and have installed pip. Then install QMK with this command:
If your system is not listed above you can install QMK manually. First ensure that you have Python 3.6 (or later) installed and have installed pip. Then install QMK with this command:
```
pip3 install qmk
python3 -m pip install qmk
export QMK_HOME='~/qmk_firmware' # Optional, set the location for `qmk_firmware`
qmk setup # This will clone `qmk/qmk_firmware` and optionally set up your build environment
First we import the `cli` object from `milc`. This is how we interact with the user and control the script's behavior. We use `@cli.argument()` to define a command line flag, `--name`. This also creates a configuration variable named `hello.name` (and the corresponding `user.name`) which the user can set so they don't have to specify the argument. The `cli.subcommand()` decorator designates this function as a subcommand. The name of the subcommand will be taken from the name of the function.
Once inside our function we find a typical "Hello, World!" program. We use `cli.log` to access the underlying [Logger Object](https://docs.python.org/3.5/library/logging.html#logger-objects), whose behavior is user controllable. We also access the value for name supplied by the user as `cli.config.hello.name`. The value for `cli.config.hello.name` will be determined by looking at the `--name` argument supplied by the user, if not provided it will use the value in the `qmk.ini` config file, and if neither of those is provided it will fall back to the default supplied in the `cli.argument()` decorator.
Once inside our function we find a typical "Hello, World!" program. We use `cli.log` to access the underlying [Logger Object](https://docs.python.org/3.6/library/logging.html#logger-objects), whose behavior is user controllable. We also access the value for name supplied by the user as `cli.config.hello.name`. The value for `cli.config.hello.name` will be determined by looking at the `--name` argument supplied by the user, if not provided it will use the value in the `qmk.ini` config file, and if neither of those is provided it will fall back to the default supplied in the `cli.argument()` decorator.
# User Interaction
@@ -56,13 +56,13 @@ There are two main methods for outputting text in a subcommand- `cli.log` and `c
You can use special tokens to colorize your text, to make it easier to understand the output of your program. See [Colorizing Text](#colorizing-text) below.
Both of these methods support built-in string formatting using python's [printf style string format operations](https://docs.python.org/3.5/library/stdtypes.html#old-string-formatting). You can use tokens such as `%s` and `%d` within your text strings then pass the values as arguments. See our Hello, World program above for an example.
Both of these methods support built-in string formatting using python's [printf style string format operations](https://docs.python.org/3.6/library/stdtypes.html#old-string-formatting). You can use tokens such as `%s` and `%d` within your text strings then pass the values as arguments. See our Hello, World program above for an example.
You should never use the format operator (`%`) directly, always pass values as arguments.
### Logging (`cli.log`)
The `cli.log` object gives you access to a [Logger Object](https://docs.python.org/3.5/library/logging.html#logger-objects). We have configured our log output to show the user a nice emoji for each log level (or the log level name if their terminal does not support unicode.) This way the user can tell at a glance which messages are most important when something goes wrong.
The `cli.log` object gives you access to a [Logger Object](https://docs.python.org/3.6/library/logging.html#logger-objects). We have configured our log output to show the user a nice emoji for each log level (or the log level name if their terminal does not support unicode.) This way the user can tell at a glance which messages are most important when something goes wrong.
The default log level is `INFO`. If the user runs `qmk -v <subcommand>` the default log level will be set to `DEBUG`.
@@ -210,7 +210,7 @@ Our tests can be found in `lib/python/qmk/tests/`. You will find both unit and i
If your PR does not include a comprehensive set of tests please add comments like this to your code so that other people know where they can help:
We use [nose2](https://nose2.readthedocs.io/en/latest/getting_started.html) to run our tests. You can refer to the nose2 documentation for more details on what you can do in your test functions.
@@ -191,7 +191,12 @@ If you define these options you will enable the associated feature, which may in
*`#define RGBLIGHT_ANIMATIONS`
* run RGB animations
*`#define RGBLIGHT_LAYERS`
* Lets you define [lighting layers](feature_rgblight.md) that can be toggled on or off. Great for showing the current keyboard layer or caps lock state.
* Lets you define [lighting layers](feature_rgblight.md?id=lighting-layers) that can be toggled on or off. Great for showing the current keyboard layer or caps lock state.
*`#define RGBLIGHT_MAX_LAYERS`
* Defaults to 8. Can be expanded up to 32 if more [lighting layers](feature_rgblight.md?id=lighting-layers) are needed.
* Note: Increasing the maximum will increase the firmware size and slow sync on split keyboards.
*`#define RGBLIGHT_LAYER_BLINK`
* Adds ability to [blink](feature_rgblight.md?id=lighting-layer-blink) a lighting layer for a specified number of milliseconds (e.g. to acknowledge an action).
@@ -12,7 +12,7 @@ I'll say that again because it's important:
!> **MAKE SURE YOU SELECT THE RIGHT VERSION!**
If your keyboard has been advertised to be powered by QMK but is not in the list, chances are a developer hasn't gotten to it yet or we haven't had a chance to merge it in yet. File an issue at [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) requesting to support that particular keyboard, if there is no active [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) for it. There are also QMK powered keyboards that are in their manufacturer's own github accounts. Double check for that as well. <!-- FIXME(skullydazed): This feels too wordy and I'm not sure we want to encourage these kinds of issues. Also, should we prompt them to bug the manufacutrer? -->
If your keyboard has been advertised to be powered by QMK but is not in the list, chances are a developer hasn't gotten to it yet or we haven't had a chance to merge it in yet. File an issue at [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) requesting to support that particular keyboard, if there is no active [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) for it. There are also QMK powered keyboards that are in their manufacturer's own GitHub accounts. Double check for that as well. <!-- FIXME(skullydazed): This feels too wordy and I'm not sure we want to encourage these kinds of issues. Also, should we prompt them to bug the manufacutrer? -->
@@ -13,7 +13,7 @@ QMK (*Quantum Mechanical Keyboard*) ist eine Open-Source-Community, welche die Q
## Bezugsquelle für QMK
Wenn Du vorhast, deine Tastatur, Tastaturbelegung oder Features zu QMK beizusteuern, geht das am einfachsten, indem Du das [Repository auf Github](https://github.com/qmk/qmk_firmware#fork-destination-box) forkst, die Änderungen in deinem lokalen Repo vornimmst und anschließend einen [Pull Request](https://github.com/qmk/qmk_firmware/pulls) einreichst.
Wenn Du vorhast, deine Tastatur, Tastaturbelegung oder Features zu QMK beizusteuern, geht das am einfachsten, indem Du das [Repository auf GitHub](https://github.com/qmk/qmk_firmware#fork-destination-box) forkst, die Änderungen in deinem lokalen Repo vornimmst und anschließend einen [Pull Request](https://github.com/qmk/qmk_firmware/pulls) einreichst.
Ansonsten kannst Du es als [zip](https://github.com/qmk/qmk_firmware/zipball/master) oder [tar](https://github.com/qmk/qmk_firmware/tarball/master) herunterladen, oder es direkt via git klonen (`git clone git@github.com:qmk/qmk_firmware.git` bzw. `git clone https://github.com/qmk/qmk_firmware.git`).
`EEPROM_DRIVER = vendor` (default) | Uses the on-chip driver provided by the chip manufacturer. For AVR, this is provided by avr-libc. This is supported on ARM for a subset of chips -- STM32F3xx, STM32F1xx, and STM32F072xB will be emulated by writing to flash. STM32L0xx and STM32L1xx will use the onboard dedicated true EEPROM. Other chips will generally act as "transient" below.
`EEPROM_DRIVER = i2c` | Supports writing to I2C-based 24xx EEPROM chips. See the driver section below.
`EEPROM_DRIVER = spi` | Supports writing to SPI-based 25xx EEPROM chips. See the driver section below.
`EEPROM_DRIVER = transient` | Fake EEPROM driver -- supports reading/writing to RAM, and will be discarded when power is lost.
`#define STM32_ONBOARD_EEPROM_SIZE` | The size of the EEPROM to use, in bytes. Erase times can be high, so it's configurable here, if not using the default value. | Minimum required to cover base _eeconfig_ data, or `1024` if VIA is enabled.
Currently QMK supports 24xx-series chips over I2C. As such, requires a working i2c_master driver configuration. You can override the driver configuration via your config.h:
?> If you find that the EEPROM is not cooperating, ensure you've correctly shifted up your EEPROM address by 1. For example, the datasheet might state the address as `0b01010000` -- the correct value of `EXTERNAL_EEPROM_I2C_BASE_ADDRESS` needs to be `0b10100000`.
Currently QMK supports 25xx-series chips over SPI. As such, requires a working spi_master driver configuration. You can override the driver configuration via your config.h:
@@ -13,7 +13,7 @@ QMK (*Quantum Mechanical Keyboard*) es una comunidad open source que mantiene el
## Cómo conseguirlo
Si estás pensando en contribuir con un keymap, teclado, or característica a QMK, la manera más sencilla es hacer un [fork del repositorio en Github](https://github.com/qmk/qmk_firmware#fork-destination-box), y clonar tu repositorio localmente para hacer los cambios, subirlos, y abir un [Pull Request](https://github.com/qmk/qmk_firmware/pulls) desde tu fork.
Si estás pensando en contribuir con un keymap, teclado, or característica a QMK, la manera más sencilla es hacer un [fork del repositorio en GitHub](https://github.com/qmk/qmk_firmware#fork-destination-box), y clonar tu repositorio localmente para hacer los cambios, subirlos, y abir un [Pull Request](https://github.com/qmk/qmk_firmware/pulls) desde tu fork.
De cualquier manera, también puedes descargarlo directamente en formatos ([zip](https://github.com/qmk/qmk_firmware/zipball/master), [tar](https://github.com/qmk/qmk_firmware/tarball/master)), o clonarlo via git (`git@github.com:qmk/qmk_firmware.git`), o https (`https://github.com/qmk/qmk_firmware.git`).
@@ -21,7 +21,7 @@ Lo diré otra vez porque es importante
!> **ASEGÚRATE DE QUE SELECCIONAS LA VERSIÓN CORRECTA!**
Si se ha anunciado que tu teclado funciona con QMK pero no está en la lista, es probable que un desarrollador no se haya encargado de él aún o que todavía no hemos tenido la oportunidad de incluirlo. Abre un issue en [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) solicitando soportar ese teclado un particular, si no hay un [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) activo para ello. Hay también teclados que funcionan con QMK que están en las cuentas de github de sus manufacturantes. Acuérdate de comprobar esto también.
Si se ha anunciado que tu teclado funciona con QMK pero no está en la lista, es probable que un desarrollador no se haya encargado de él aún o que todavía no hemos tenido la oportunidad de incluirlo. Abre un issue en [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) solicitando soportar ese teclado un particular, si no hay un [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) activo para ello. Hay también teclados que funcionan con QMK que están en las cuentas de GitHub de sus manufacturantes. Acuérdate de comprobar esto también.
@@ -38,5 +38,6 @@ For use in keyboards where refreshing ```NUM_KEYS``` 8-bit counters is computati
appropriate for the ErgoDox models; the matrix is rotated 90°, and hence its "rows" are really columns, and each finger only hits a single "row" at a time in normal use.
* eager_pk - debouncing per key. On any state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that key
* sym_g - debouncing per keyboard. On any state change, a global timer is set. When ```DEBOUNCE``` milliseconds of no changes has occured, all input changes are pushed.
* sym_pk - debouncing per key. On any state change, a per-key timer is set. When ```DEBOUNCE``` milliseconds of no changes have occured on that key, the key status change is pushed.
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)
This is an integration of Peter Fleury's LCD library. This page will explain the basics. [For in depth documentation visit his page.](http://www.peterfleury.epizy.com/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.
@@ -50,8 +50,8 @@ 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 do so call `lcd_clrscr()`.
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 methods available 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)
There are more methods available to control the display. [For in depth documentation please visit the linked page.](http://www.peterfleury.epizy.com/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
Raw HID allows for bidirectional communication between QMK and the host computer over an HID interface. This has many potential use cases, such as switching keymaps on the fly or changing RGB LED colors and modes.
There are two main components to getting raw HID working with your keyboard.
## Keyboard firmware
The implementation is fairly straightforward for the firmware.
In your `rules.mk` add:
```make
RAW_ENABLE= yes
```
In your `keymap.c` include `"raw_hid.h"` and implement the following:
```C
voidraw_hid_receive(uint8_t*data,uint8_tlength){
// Your code goes here. data is the packet received from host.
}
```
The `"raw_hid.h"` header also declares `void raw_hid_send(uint8_t *data, uint8_t length);` which allows sending packets from keyboard to host. As an example, it can also be used for debugging when building your host application by returning all data back to the host.
```C
voidraw_hid_receive(uint8_t*data,uint8_tlength){
raw_hid_send(data,length);
}
```
`raw_hid_receive` can receive variable size packets from host with maximum length `RAW_EPSIZE`. `raw_hid_send` on the other hand can send packets to host of exactly `RAW_EPSIZE` length, therefore it should be used with data of length `RAW_EPSIZE`.
Make sure to flash raw enabled firmware before proceeding with working on the host side.
## Host (Windows/macOS/Linux)
This is the more complicated part as it will require some digging.
To connect your host computer to your keyboard with raw HID you need four pieces of information about your keyboard:
1. Vendor ID
2. Product ID
3. Usage Page
4. Usage
The first two can easily be found in your keyboard's `config.h` in the keyboard's main directory under `VENDOR_ID` and `PRODUCT_ID`.
The final two can be overridden in your keyboard's `config.h` in the keyboard's main directory by redefining the values: `#define RAW_USAGE_PAGE 0xFF60` and `#define RAW_USAGE_ID 0x61`.
By default, **Usage Page** is `0xFF60` and **Usage** is `0x61`.
### Building your host
You can build your host using any language that has an available HID implementation library if you don't wish to make your own. The ones we know of for popular languages are:
This is not an exhaustive cross-platform list but should get you started. There are no special requirements for using raw HID so any HID library should work.
Now that you have all four pieces of information required to open HID interface to your keyboard. All you need to do is use your library's available functions to open the device with its ID parameters.
Note that Vendor ID and Product ID are not actually required to open the device. They are used only to filter to a specific device out of the many HID devices you have plugged in. Many libraries will give you the option to open the device using Product Name or Manufacturer Name instead, `node-hid` being a prime example. This will create issues for devices with builtin USB Hub or any extra HID interfaces where you will have multiple interfaces with the same name or from the same manufacturer. The Vendor ID together with Product ID create a unique designation to a single interface and will not exhibit this problem. Therefore, even if your library doesn't require you to, it is best to use them to avoid issues.
Unlike Vendor ID and Product ID though, Usage Page and Usage are necessary for successful communication.
It should go without saying that regardless of the library you're using, you should always make sure to close the interface when finished. Depending on the operating system and your particular environment there may be issues connecting to it again afterwards with another client or another instance of the same client if it's not explicitly closed.
|`rgb_matrix_is_enabled()` |Gets current on/off status |
|`rgb_matrix_get_mode()` |Gets current mode |
|`rgb_matrix_get_hue()` |Gets current hue |
|`rgb_matrix_get_sat()` |Gets current sat |
|`rgb_matrix_get_val()` |Gets current val |
|`rgb_matrix_get_hsv()` |Gets hue, sat, and val and returns a [`HSV` structure](https://github.com/qmk/qmk_firmware/blob/7ba6456c0b2e041bb9f97dbed265c5b8b4b12192/quantum/color.h#L56-L61)|
|`rgb_matrix_get_speed()` |Gets current speed |
|`rgb_matrix_get_suspend_state()` |Gets current suspend state |
Check out [this video](https://youtube.com/watch?v=VKrpPAHlisY) for a demonstration.
@@ -103,8 +104,8 @@ Note: For versions older than 0.6.117, The mode numbers were written directly. I
Use these defines to add or remove animations from the firmware. When you are running low on flash space, it can be helpful to disable animations you are not using.
By including `#define RGBLIGHT_LAYERS` in your `config.h` file you can enable lighting layers. These make
it easy to use your underglow LEDs as status indicators to show which keyboard layer is currently active, or the state of caps lock, all without disrupting any animations. [Here's a video](https://youtu.be/uLGE1epbmdY) showing an example of what you can do.
By default, 8 layers are possible. This can be expanded to as many as 32 by overriding the definition of `RGBLIGHT_MAX_LAYERS` in `config.h` (e.g. `#define RGBLIGHT_MAX_LAYERS 32`). Please note, if you use a split keyboard, you will need to flash both sides of the split after changing this. Also, increasing the maximum will increase the firmware size, and will slow sync on split keyboards.
To define a layer, we modify `keymap.c` to list out LED ranges and the colors we want to overlay on them using an array of `rgblight_segment_t` using the `RGBLIGHT_LAYER_SEGMENTS` macro. We can define multiple layers and enable/disable them independently:
@@ -8,9 +8,20 @@ QMK Firmware has a generic implementation that is usable by any board, as well a
For this, we will mostly be talking about the generic implementation used by the Let's Split and other keyboards.
!> ARM is not yet supported for Split Keyboards. Progress is being made, but we are not quite there, yet.
!> ARM is not yet fully supported for Split Keyboards and has many limitations. Progress is being made, but we have not yet reached 100% feature parity.
If you use more than one keyboard with a similar keymap, you might see the benefit in being able to share code between them. Create your own folder in `users/` named the same as your keymap (ideally your github username, `<name>`) with the following structure:
If you use more than one keyboard with a similar keymap, you might see the benefit in being able to share code between them. Create your own folder in `users/` named the same as your keymap (ideally your GitHub username, `<name>`) with the following structure:
*`/users/<name>/` (added to the path automatically)
*`readme.md` (optional, recommended)
@@ -73,7 +73,7 @@ The reason for this, is that `<name>.h` won't be added in time to add settings (
## Readme (`readme.md`)
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).
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).
You can use this as a template:
```
@@ -93,7 +93,7 @@ You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
```
You'd want to replace the year, name, email and github username with your info.
You'd want to replace the year, name, email and GitHub username with your info.
Additionally, this is a good place to document your code, if you wish to share it with others.
@@ -13,7 +13,7 @@ QMK (*Quantum Mechanical Keyboard*) est une communauté open source qui maintien
## Comment l'obtenir
Si vous souhaitez contribuer à une disposition de clavier (keymap), ou à des fonctionnalités de QMK alors le plus simple est de [forker le dépôt avec Github](https://github.com/qmk/qmk_firmware#fork-destination-box) puis cloner le dépôt localement pour y faire des changements. Vous pourrez pousser vos changements sur github puis ouvrir un [Pull Request](https://github.com/qmk/qmk_firmware/pulls) depuis votre fork Github.
Si vous souhaitez contribuer à une disposition de clavier (keymap), ou à des fonctionnalités de QMK alors le plus simple est de [forker le dépôt avec GitHub](https://github.com/qmk/qmk_firmware#fork-destination-box) puis cloner le dépôt localement pour y faire des changements. Vous pourrez pousser vos changements sur GitHub puis ouvrir un [Pull Request](https://github.com/qmk/qmk_firmware/pulls) depuis votre fork GitHub.
Sinon, vous pouvez aussi le télécharger directement en ([zip](https://github.com/qmk/qmk_firmware/zipball/master), [tar](https://github.com/qmk/qmk_firmware/tarball/master)), ou le cloner avec git en ssh (`git@github.com:qmk/qmk_firmware.git`), ou https (`https://github.com/qmk/qmk_firmware.git`).
@@ -6,11 +6,11 @@ GitHub peut être un peu compliqué pour ceux qui n'y sont pas familier. Ce guid
Commencez par la [page GitHub de QMK](https://github.com/qmk/qmk_firmware), et vous verrez un bouton dans le coin en haut à droite qui indique "Fork":


Si vous faites partie d'une organisation, vous aurez besoin de savoir quel compte utiliser pour le fork. Dans la plupart des cas, vous voudrez créer le fork dans votre compte personnel. Une fois le fork complet (cela peut quelques fois prendre un peu de temps), appuyez sur le bouton "Clone or download":


Faites attention à sélectionner "HTTPS", et sélectionnez le lien et copiez-le:
Cela vous change la branche courante en master, synchronise les données de références du dépôt QMK vers votre ordinateur. La commande pull tire les données de références vers votre branche courante puis les y téleverse. La commande push permet de pousser la branche courante (master) vers votre fork github.
Cela vous change la branche courante en master, synchronise les données de références du dépôt QMK vers votre ordinateur. La commande pull tire les données de références vers votre branche courante puis les y téleverse. La commande push permet de pousser la branche courante (master) vers votre fork GitHub.
This project includes a Docker workflow that will allow you to build a new firmware for your keyboard very easily without major changes to your primary operating system. This also ensures that when you clone the project and perform a build, you have the exact same environment as anyone else and the QMK build infrastructure. This makes it much easier for people to help you troubleshoot any issues you encounter.
## Requirements
The main prerequisite is a working `docker` install.
# For example: util/docker_build.sh planck/rev6:default
```
This will compile the desired keyboard/keymap and leave the resulting `.hex` or `.bin` file in the QMK directory for you to flash. If `:keymap` is omitted, all keymaps are used. Note that the parameter format is the same as when building with `make`.
There is also support for building _and_ flashing the keyboard straight from Docker by specifying the `target` as well:
```bash
util/docker_build.sh keyboard:keymap:target
# For example: util/docker_build.sh planck/rev6:default:flash
```
You can also start the script without any parameters, in which case it will ask you to input the build parameters one by one, which you may find easier to use:
```bash
util/docker_build.sh
# Reads parameters as input (leave blank for all keyboards/keymaps)
```
## FAQ
### Why can't I flash on Windows/macOS
On Windows and macOS, it requires [Docker Machine](http://gw.tnode.com/docker/docker-machine-with-usb-support-on-windows-macos/) to be running. This is tedious to set up, so it's not recommended; use [QMK Toolbox](https://github.com/qmk/qmk_toolbox) instead.
!> Docker for Windows requires [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v) to be enabled. This means that it cannot work on versions of Windows which don't have Hyper-V, such as Windows 7, Windows 8 and **Windows 10 Home**.
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.
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.
?> 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":
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":


If you're a part of an organization, you'll need to choose which account to fork it to. In most circumstances, you'll want to fork it to your personal account. Once your fork is completed (sometimes this takes a little while), click the "Clone or Download" button:


And be sure to select "HTTPS", and select the link and copy it:
@@ -54,7 +54,7 @@ To https://github.com/whoeveryouare/qmk_firmware.git
+ 20043e64...7da94ac5 master -> master
```
Your changes now exist on your fork on Github - if you go back there (`https://github.com/<whoeveryouare>/qmk_firmware`), you can create a "New Pull Request" by clicking this button:
Your changes now exist on your fork on GitHub - if you go back there (`https://github.com/<whoeveryouare>/qmk_firmware`), you can create a "New Pull Request" by clicking this button:
If you want to program via the command line you can uncomment the ['modifyvm'] lines in the Vagrantfile to enable the USB passthrough into Linux and then program using the command line tools like dfu-util/dfu-programmer or you can install the Teensy CLI version.
@@ -14,7 +14,7 @@ QMK (*Quantum Mechanical Keyboard*) היא קהילת קוד פתוח (open sour
## איך להשיג אותה
אם אתם מתכננים לתרום מיפוי מקשים, מקלדת או יכולת ל QMK, הדבר הקל ביותר הוא [לעשות פורק לריפו בGithub](https://github.com/qmk/qmk_firmware#fork-destination-box), ולעשות קלון לריפו בסביבה המקומית ושם לבצע את השינויים שלכם, לדחוף אותם ולפתוח [Pull Request](https://github.com/qmk/qmk_firmware/pulls) מהפורק שלך.
אם אתם מתכננים לתרום מיפוי מקשים, מקלדת או יכולת ל QMK, הדבר הקל ביותר הוא [לעשות פורק לריפו בGitHub](https://github.com/qmk/qmk_firmware#fork-destination-box), ולעשות קלון לריפו בסביבה המקומית ושם לבצע את השינויים שלכם, לדחוף אותם ולפתוח [Pull Request](https://github.com/qmk/qmk_firmware/pulls) מהפורק שלך.
אחרת, אפשר להוריד את הקושחה באופן ישיר ([zip](https://github.com/qmk/qmk_firmware/zipball/master), [tar](https://github.com/qmk/qmk_firmware/tarball/master)), או לשכפל אותה באמצעות git (`git@github.com:qmk/qmk_firmware.git`), או https (`https://github.com/qmk/qmk_firmware.git`).
Github עלול להיות קצת טריקי למי שלא מכיר את העבודה איתו - מדריך זה ילווה אתכם שלב אחר שלב דרך ביצוע פעולות fork, clone ו-pull request עם QMK.
GitHub עלול להיות קצת טריקי למי שלא מכיר את העבודה איתו - מדריך זה ילווה אתכם שלב אחר שלב דרך ביצוע פעולות fork, clone ו-pull request עם QMK.
?> מדריך זה מניח שאתם מרגישים בנוח עם הרצה של פקודות בסביבת command line (שורת הפקודה) ו-git מותקן במערכת שלכם.
התחילו ב- [עמוד של QMK ב-Github](https://github.com/qmk/qmk_firmware), ותצמאו כפתור בחלק העליון מימין עם התיכוב "Fork":
התחילו ב- [עמוד של QMK ב-GitHub](https://github.com/qmk/qmk_firmware), ותצמאו כפתור בחלק העליון מימין עם התיכוב "Fork":


אם אתם חלק מארגון, תצטרכו לבחור לאיזה חשבון לבצע פעולת fork. ברוב המבקרים, תרצו לבצע fork לתוך החשבון הפרטי שלכם. ברגע שה-fork הסתיים (לפעמים זה יכול לקחת קצת זמן) הקליקו על כפתור ה-"Clone or Download":


תוודאו שאתם בוחרים באופצייה של "HTTPS", בחרו את הקישור והעתיקו אותו:
@@ -115,12 +115,18 @@ The simplest and quickest way to get things back to normal is to flash only a bo
You can find the stock bootloaders in the [`util/` folder](https://github.com/qmk/qmk_firmware/tree/master/util). Be sure to flash the correct bootloader for your chip:
*[`atmega32u4`](https://github.com/qmk/qmk_firmware/blob/master/util/bootloader_atmega32u4_1_0_0.hex) - Most keyboards, Planck Rev 1-5, Preonic Rev 1-2
* [`Pro Micro`](https://github.com/sparkfun/Arduino_Boards/blob/master/sparkfun/avr/bootloaders/caterina/Caterina-promicro16.hex) - The default bootloader for Pro Micro controllers
If you're not sure what your board uses, look in the `rules.mk` file for the keyboard in QMK. The `MCU =` line will have the value you need. It may differ between different versions of the board.
If you're not sure what your board uses, look in the `rules.mk` file for the keyboard in QMK. The `MCU` and `BOOTLOADER` lines will have the value you need. It may differ between different versions of the board.
original document: 0.8.134:docs/feature_leader_key.md
git diff 0.8.134 HEAD -- docs/feature_leader_key.md | cat
-->
もしあなたが Vim を使ったことがある場合、リーダーキーは何であるかを知っています。そうでなければ、素晴らしい概念を発見しようとしています。:) 例えば、Alt+Shift+W を押す(3つのキーを同時に押す)代わりに、キーの_シーケンス_を押すことができたらどうでしょう?つまり、特別なモディファイア (リーダーキー)を押して、続けて W と C を押すと (単純にキーを高速に繋げます)、何かが起こります。
Now that you've built a custom firmware file you'll want to flash your keyboard.
Now that you've built a custom firmware file you'll want to flash your keyboard.
## Put Your Keyboard into DFU (Bootloader) Mode
In order to flash your custom firmware you must first put your keyboard into a special flashing mode. While it is in this mode you will not be able to type or otherwise use your keyboard. It is very important that you do not unplug the keyboard or otherwise interrupt the flashing process while the firmware is being written.
Different keyboards have different ways to enter this special mode. If your PCB currently runs QMK, TMK, or PS2AVRGB (Bootmapper Client) and you have not been given specific instructions, try the following, in order:
* Hold down both shift keys and press `Pause`
* Hold down both shift keys and press `B`
* Unplug your keyboard, hold down the Spacebar and `B` at the same time, plug in your keyboard and wait a second before releasing the keys
* Unplug your keyboard, hold down the top or bottom left key (usually Escape or Left Control) and plug in your keyboard
* Press the physical `RESET` button, usually located on the underside of the PCB
* Locate header pins on the PCB labeled `RESET` and `GND`, and short them together while plugging your PCB in
If you've attempted all of the above to no avail, and the main chip on the board says `STM32` on it, this may be a bit more complicated. Generally your best bet is to ask on [Discord](https://discord.gg/Uq7gcHh) for assistance. It's likely some photos of the board will be asked for -- if you can get them ready beforehand it'll help move things along!
Otherwise, you should see a message in yellow, similar to this in QMK Toolbox:
and this bootloader device will also be present in Device Manager, System Information.app, or `lsusb`.
## Flashing Your Keyboard with QMK Toolbox
The simplest way to flash your keyboard will be with the [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases).
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), proceed down to [Flash Your Keyboard From The Command Line](#flash-your-keyboard-from-the-command-line).
However, the Toolbox is currently only available for Windows and macOS. If you're using Linux (or just wish to flash the firmware from the command line), skip to the [Flash your Keyboard from the Command Line](#flash-your-keyboard-from-the-command-line) section.
### Load The File Into QMK Toolbox
### 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.
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 folder in Explorer or Finder.
#### Windows
@@ -38,65 +61,44 @@ For example, the `planck/rev5` with a `default` keymap will have this filename:
planck_rev5_default.hex
```
Once you have located your firmware file drag it into the "Local file" box in QMK Toolbox, or click "Open" and navigate to where your firmware file is stored.
### Put Your Keyboard Into DFU (Bootloader) Mode
In order to flash your custom firmware you have to put your keyboard into a special flashing mode. While it is in this mode you will not be able to type or otherwise use your keyboard. It is very important that you do not unplug your keyboard or otherwise interrupt the flashing process while the firmware is being written.
Different keyboards have different ways to enter this special mode. If your PCB currently runs QMK or TMK and you have not been given specific instructions try the following, in order:
* Hold down both shift keys and press `Pause`
* Hold down both shift keys and press `B`
* Unplug your keyboard, hold down the Spacebar and `B` at the same time, plug in your keyboard and wait a second before releasing the keys
* Press the physical `RESET` button on the bottom of the PCB
* Locate header pins on the PCB labeled `BOOT0` or `RESET`, short those together while plugging your PCB in
When you are successful you will see a message similar to this in QMK Toolbox:
Once you have located your firmware file drag it into the "Local file" box in QMK Toolbox, or click "Open" and navigate to where your firmware file is stored.
### Flash Your Keyboard
Click the `Flash` button in QMK Toolbox. You will see output similar to the following:
This has been made pretty simple compared to what it used to be. When you are ready to compile and flash your firmware, open up your terminal window and run the flash command:
This has been made pretty simple compared to what it used to be. When you are ready to compile and flash your firmware, open up your terminal window and run the flash command:
qmk flash
If you have not configured your keyboard/keymap name, or you have multiple keyboards, you can specify the keyboard and keymap:
If you have not configured your keyboard/keymap name in the CLI, or you have multiple keyboards, you can specify the keyboard and keymap:
qmk flash -kb <my_keyboard> -km <my_keymap>
This will check the keyboard's configuration, and then attempt to flash it based on the specified bootloader. This means that you don't need to know which bootloader that your keyboard uses. Just run the command, and let the command do the heavy lifting.
This will check the keyboard's configuration, and then attempt to flash it based on the specified bootloader. This means that you don't need to know which bootloader that your keyboard uses. Just run the command, and let the command do the heavy lifting.
However, this does rely on the bootloader being set by the keyboard. If this information is not configured, or you're using a board that doesn't have a supported target to flash it, you will see this error:
However, this does rely on the bootloader being set by the keyboard. If this information is not configured, or you're using a board that doesn't have a supported target to flash it, you will see this error:
WARNING: This board's bootloader is not specified or is not supported by the ":flash" target at this time.
`python3 -m pip install --user qmk` (on Arch-based distros you can also try the `qmk` package from AUR (**note**: it's maintained by a community member): `yay -S qmk`)
### FreeBSD
You will need to install Git and Python. It's possible that you already have both, but if not, run the following commands to install them:
pkg install git python3
Make sure that `$HOME/.local/bin` is added to your `$PATH` so that locally install Python packages are available.
Once installed, you can install QMK CLI:
python3 -m pip install --user qmk
## 3. Run QMK Setup :id=set-up-qmk
@@ -78,7 +93,19 @@ After installing QMK you can set it up with this command:
In most situations you will want to answer Yes to all of the prompts.
?> If you already know [how to use GitHub](getting_started_github.md), we recommend that you create your own fork and use `qmk setup <github_username>` to clone your personal fork. If you don't know what that means you can safely ignore this message.
?>**Note on Debian, Ubuntu and their derivatives**:
It's possible, that you will get an error saying something like: `bash: qmk: command not found`.
This is due to a [bug](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839155) Debian introduced with their Bash 4.4 release, which removed `$HOME/.local/bin` from the PATH. This bug was later fixed on Debian and Ubuntu.
Sadly, Ubuntu reitroduced this bug and is [yet to fix it](https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1588562).
Luckily, the fix is easy. Run this as your user: `echo "PATH=$HOME/.local/bin:$PATH" >> $HOME/.bashrc && source $HOME/.bashrc`
?>**Note on FreeBSD**:
It is suggested to run `qmk setup` as a non-`root` user to start with, but this will likely identify packages that need to be installed to your
base system using `pkg`. However the installation will probably fail when run as an unprivileged user.
To manually install the base dependencies, run `./util/qmk_install.sh` either as `root`, or with `sudo`.
Once that completes, re-run `qmk setup` to complete the setup and checks.
?> If you already know [how to use GitHub](getting_started_github.md), we recommend that you create your own fork and use `qmk setup <github_username>/qmk_firmware` to clone your personal fork. If you don't know what that means you can safely ignore this message.
## 4. Test Your Build Environment
@@ -108,7 +135,7 @@ Most people new to QMK only have 1 keyboard. You can set this keyboard as your d
qmk config user.keyboard=clueboard/66/rev4
You can also set your default keymap name. Most people use their github username here, and we recommend that you do too.
You can also set your default keymap name. Most people use their GitHub username here, and we recommend that you do too.
@@ -102,7 +102,7 @@ There are a number of extensions that you may want to install:
This installs a bunch of Git related tools that may make using Git with QMK Firmware easier.
* [EditorConfig for VS Code](https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig) - _[Optional]_ - Helps to keep the code to the QMK Coding Conventions.
* [Bracket Pair Colorizer 2](https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer-2) - _[Optional]_ - This color codes the brackets in your code, to make it easier to reference nested code.
* [Github Markdown Preview](https://marketplace.visualstudio.com/items?itemName=bierner.github-markdown-preview) - _[Optional]_ - Makes the markdown preview in VS Code more like GitHub's.
* [GitHub Markdown Preview](https://marketplace.visualstudio.com/items?itemName=bierner.github-markdown-preview) - _[Optional]_ - Makes the markdown preview in VS Code more like GitHub's.
* [VS Live Share Extension Pack](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare-pack) - _[Optional]_ - This extension allows somebody else to access your workspace (or you to access somebody else's workspace) and help out. This is great if you're having issues and need some help from somebody.
* [VIM Keymap](https://marketplace.visualstudio.com/items?itemName=GiuseppeCesarano.vim-keymap) - _[Optional]_ - For those that prefer VIM style keybindings. There are other options for this, too.
* [Travis CI Status](https://marketplace.visualstudio.com/items?itemName=felixrieseberg.vsc-travis-ci-status) - _[Optional]_ - This shows the current Travis CI status, if you have it set up.
# Arm/ChibiOS Early Initialization :id=chibios-early-init
This page describes a part of QMK that is a somewhat advanced concept, and is only relevant to keyboard designers.
QMK uses ChibiOS as the underlying layer to support a multitude of Arm-based devices. Each ChibiOS-supported keyboard has a low-level board definition which is responsible for initializing hardware peripherals such as the clocks, and GPIOs.
Older QMK revisions required duplication of these board definitions inside your keyboard's directory in order to override such early initialization points; this is now abstracted into the following APIs, and allows usage of the board definitions supplied with ChibiOS itself. Check `<qmk_firmware>/lib/chibios/os/hal/boards` for the list of official definitions. If your keyboard needs extra initialization at a very early stage, consider providing keyboard-level overrides of the following APIs:
The function `early_hardware_init_pre` is the earliest possible code that can be executed by a keyboard firmware. This is intended as a replacement for the ChibiOS board definition's `__early_init` function, and is the equivalent of executing at the start of the function.
This is executed before RAM gets cleared, and before clocks or GPIOs are configured; any delays or preparation using GPIOs is not likely to work at this point. After executing this function, RAM on the MCU may be zero'ed. Assigning values to variables during execution of this function may be overwritten.
As such, if you wish to override this API consider limiting use to writing to low-level registers. The default implementation of this function can be configured to jump to bootloader if a `RESET` key was pressed, by ensuring `#define EARLY_INIT_PERFORM_BOOTLOADER_JUMP TRUE` is in the keyboard's `config.h` file.
To implement your own version of this function, in your keyboard's source files:
The function `early_hardware_init_post` is the next earliest possible code that can be executed by a keyboard firmware. This is executed after RAM has been cleared, and clocks and GPIOs are configured. This is intended as a replacement for the ChibiOS board definition's `__early_init` function, and is the equivalent of executing at the end of the function.
Much like `early_hardware_init_pre`, ChibiOS has not yet been initialized either, so the same restrictions on delays and timing apply.
If you wish to override this API, consider limiting functionality to register writes, variable initialization, and GPIO toggling. The default implementation of this function is to do nothing.
To implement your own version of this function, in your keyboard's source files:
```c
voidearly_hardware_init_post(void){
// toggle GPIO pins and write to variables
}
```
## `board_init()` :id=board-init
The function `board_init` is executed directly after the ChibiOS initialization routines have completed. At this stage, all normal low-level functionality should be available for use (including timers and delays), with the restriction that USB is not yet connected. This is intended as a replacement for the ChibiOS board definition's `boardInit` function.
The default implementation of this function is to do nothing.
To implement your own version of this function, in your keyboard's source files:
Since the Proton C is a drop-in replacement for a Pro Micro we've made it easy to use. This page documents a handy automated process for converting keyboards, as well as documenting the manual process if you'd like to make use of Proton C features that aren't available on Pro Micros.
## Automatic Conversion
If a board currently supported in QMK uses a Pro Micro (or compatible board) and you want to use the Proton C, you can generate the firmware by appending `CONVERT_TO_PROTON_C=yes` (or `CTPC=yes`) to your make argument, like this:
make 40percentclub/mf68:default CTPC=yes
@@ -8,13 +12,15 @@ You can add the same argument to your keymap's `rules.mk`, which will accomplish
This exposes the `CONVERT_TO_PROTON_C` flag that you can use in your code with `#ifdef`s, like this:
#ifdef CONVERT_TO_PROTON_C
// Proton C code
#else
// Pro Micro code
#endif
```c
#ifdef CONVERT_TO_PROTON_C
// Proton C code
#else
// Pro Micro code
#endif
```
Before being able to compile, you may get some errors about `PORTB/DDRB`, etc not being defined, so you'll need to convert the keyboard's code to use the [GPIO Controls](internals_gpio_control.md) that will work for both ARM and AVR. This shouldn't affect the AVR builds at all.
If you get errors about `PORTB/DDRB`, etc not being defined, so you'll need to convert the keyboard's code to use the [GPIO Controls](internals_gpio_control.md) that will work for both ARM and AVR. This shouldn't affect the AVR builds at all.
The Proton C only has one on-board LED (C13), and by default, the TXLED (D5) is mapped to it. If you want the RXLED (B0) mapped to it instead, add this like to your `config.h`:
@@ -30,4 +36,55 @@ These are defaults based on what has been implemented for ARM boards.
| [Backlight](feature_backlight.md) | Forces [task driven PWM](feature_backlight.md#software-pwm-driver) until ARM can provide automatic configuration |
| USB Host (e.g. USB-USB converter) | Not supported (USB host code is AVR specific and is not currently supported on ARM) |
| [Split keyboards](feature_split_keyboard.md) | Not supported yet |
| [Split keyboards](feature_split_keyboard.md) | Partial - heavily dependent on enabled features |
## Manual Conversion
To use the Proton C natively, without having to specify `CTPC=yes`, you need to change the `MCU` line in `rules.mk`:
```
MCU = STM32F303
```
Remove these variables if they exist:
*`BOOTLOADER`
*`EXTRA_FLAGS`
Finally convert all pin assignments in `config.h` to the stm32 equivalents.
| Pro Micro Left | Proton C Left | | Proton C Right | Pro Micro Right |
@@ -12,7 +12,7 @@ QMK (*Quantum Mechanical Keyboard*) é uma comunidade de código aberto que mant
## Como obter e usar o QMK
Se você planeja contribuir com um _keymap_ ("mapa de teclas"), teclado ou recursos para o QMK, o jeito mais fácil é [percorrer o repositório através do Github](https://github.com/qmk/qmk_firmware#fork-destination-box) e clonar seu repositório localmente para fazer suas alterações, dê um _push_ nelas e abra uma [_Pull request_](https://github.com/qmk/qmk_firmware/pulls) no seu fork.
Se você planeja contribuir com um _keymap_ ("mapa de teclas"), teclado ou recursos para o QMK, o jeito mais fácil é [percorrer o repositório através do GitHub](https://github.com/qmk/qmk_firmware#fork-destination-box) e clonar seu repositório localmente para fazer suas alterações, dê um _push_ nelas e abra uma [_Pull request_](https://github.com/qmk/qmk_firmware/pulls) no seu fork.
Caso contrário, você pode cloná-lo diretamente com `git clone https://github.com/qmk/qmk_firmware`. Não faça o download dos arquivos zip ou tar; é necessário um repositório git para baixar os submódulos para compilar.
@@ -8,7 +8,7 @@ There are actually separate functions that you can use there, depending on what
### `update_tri_layer(x, y, z)`
The first is the `update_tri_layer(x, y, z)` function. This function check to see if layers `x` and `y` are both on. If they are both on, then it runs on layer `z`. Otherwise, if both `x` and `y` are not both on (either only one is, or neither is), then it runs off layer `z`.
The first is the `update_tri_layer(x, y, z)` function. This function check to see if layers `x` and `y` are both on. If they are both on, then it turns on layer `z`. Otherwise, if both `x` and `y` are not both on (either only one is, or neither is), then it turns off layer `z`.
This function is useful if you want to create specific keys that have this functionality, but other layer keycodes won't do this.
The other function is `update_tri_layer_state(state, x, y, z)`. This function is meant to be called from they [`layer_state_set_*` functions](custom_quantum_functions.md#layer-change-code). This means that any time that you use a keycode to change the layer, this will be checked. So you could use `LT(layer, kc)` to change the layer and it will trigger the same layer check.
The other function is `update_tri_layer_state(state, x, y, z)`. This function is meant to be called from the [`layer_state_set_*` functions](custom_quantum_functions.md#layer-change-code). This means that any time that you use a keycode to change the layer, this will be checked. So you could use `LT(layer, kc)` to change the layer and it will trigger the same layer check.
The caveat to this method is that you cannot access the `z` layer without having `x` and `y` layers on, since if you try to activate just layer `z`, it will run this code and turn off layer `z` before you could use it.
@@ -46,9 +46,6 @@ An IDE that is popular with many C developers.
## Firmware
The software that controls your MCU.
## FLIP
Software provided by Atmel for flashing AVR devices. We generally recommend [QMK Flasher](https://github.com/qmk/qmk_flasher) instead, but for some advanced use cases FLIP is required.
@@ -6,10 +6,10 @@ GitHub может показаться несколько сложным для
Откройте [страницу QMK на GitHub] (https://github.com/qmk/qmk_firmware), и в правом верхнем углу вы увидите кнопку с надписью "Fork":


Если вы состоите в какой-либо организации, вам нужно выбрать учетную запись, к которой будет привязан форк. В большинстве случаев это будет личной аккаунт. Как только ваш форк будет завершен (иногда это занимает немного времени), нажмите кнопку "Clone or Download":


И обязательно выберите "HTTPS", затем выделите ссылку и скопируйте ее:
| bit bang | :heavy_check_mark: | :heavy_check_mark: |
| USART Half-duplex | | :heavy_check_mark: |
## Driver configuration
### Bitbang
Default driver, the absence of configuration assumes this driver. To configure it, add this to your rules.mk:
```make
SERIAL_DRIVER= bitbang
```
Configure the driver via your config.h:
```c
#define SOFT_SERIAL_PIN D0 // or D1, D2, D3, E6
#define SELECT_SOFT_SERIAL_SPEED 1 // or 0, 2, 3, 4, 5
// 0: about 189kbps (Experimental only)
// 1: about 137kbps (default)
// 2: about 75kbps
// 3: about 39kbps
// 4: about 26kbps
// 5: about 20kbps
```
#### ARM
!> The bitbang driver causes connection issues with bitbang WS2812 driver
Along with the generic options above, you must also turn on the `PAL_USE_CALLBACKS` feature in your halconf.h.
### USART Half-duplex
Targeting STM32 boards where communication is offloaded to a USART hardware device. The advantage is that this provides fast and accurate timings. `SOFT_SERIAL_PIN` for this driver is the configured USART TX pin. **The TX pin must have appropriate pull-up resistors**. To configure it, add this to your rules.mk:
```make
SERIAL_DRIVER= usart
```
Configure the hardware via your config.h:
```c
#define SOFT_SERIAL_PIN B6 // USART TX pin
#define SELECT_SOFT_SERIAL_SPEED 1 // or 0, 2, 3, 4, 5
@@ -16,9 +16,26 @@ No special setup is required - just connect the `SS`, `SCK`, `MOSI` and `MISO` p
You may use more than one slave select pin, not just the `SS` pin. This is useful when you have multiple devices connected and need to communicate with them individually.
`SPI_SS_PIN` can be passed to `spi_start()` to refer to `SS`.
## ARM Configuration
## ChibiOS/ARM Configuration
ARM support for this driver is not ready yet. Check back later!
You'll need to determine which pins can be used for SPI -- as an example, STM32 parts generally have multiple SPI peripherals, labeled SPI1, SPI2, SPI3 etc.
To enable SPI, modify your board's `halconf.h` to enable SPI - both `HAL_USE_SPI` and `SPI_USE_WAIT` should be `TRUE`, and `SPI_SELECT_MODE` should be `SPI_SELECT_MODE_PAD`.
Then, modify your board's `mcuconf.h` to enable the SPI peripheral you've chosen -- in the case of using SPI2, modify `STM32_SPI_USE_SPI2` to be `TRUE`.
As per the AVR configuration, you may select any other standard GPIO as a slave select pin, and can be supplied to `spi_start()`.
Configuration-wise, you'll need to set up the peripheral as per your MCU's datasheet -- the defaults match the pins for a Proton-C, i.e. STM32F303.
|`2` |Leading edge falling|Sample on leading edge |
|`3` |Leading edge falling|Sample on trailing edge|
-`uint8_t divisor`
-`uint16_t divisor`
The SPI clock divisor, will be rounded up to the nearest power of two. This number can be calculated by dividing the MCU's clock speed by the desired SPI clock speed. For example, an MCU running at 8 MHz wanting to talk to an SPI device at 4 MHz would set the divisor to `2`.
#### Return Value
`false` if the supplied parameters are invalid or the SPI peripheral is already in use, or `true`.
@@ -12,6 +12,6 @@ If you need help with something, the best place to get quick support is going to
The official QMK forum is [/r/olkb](https://reddit.com/r/olkb) on [reddit.com](https://reddit.com).
## Github Issues
## 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.
This page helps you build up your QMK knowledge by introducing the basics first and guiding you to understanding all the concepts you need to know to be proficient with QMK.
# Beginning Topics
If you read nothing else you should read the documents in this section. After reading the [Tutorial](newbs.md) you should be able to create a basic keymap, compile it, and flash it to your keyboard. The remaining documents will flesh out your knowledge of these basics.
* **Learn How To Use QMK Tools**
* [Tutorial](newbs.md)
* [CLI](cli.md)
* [GIT](newbs_git_best_practices.md)
* **Learn About Keymaps**
* [Layers](feature_layers.md)
* [Keycodes](keycodes.md)
* The full list of keycodes you can use. Note that some may require knowledge found in the Intermediate or Advanced Topics.
* **Configuring IDEs** - Optional
* [Eclipse](other_eclipse.md)
* [VS Code](other_vscode.md)
# Intermediate Topics
These topics start to dig into some of the features that QMK supports. You don't have to read all of these documents, but some of the documents in the Advanced Topics section won't make sense if you skip over some of these.
* **Learn How To Configure Features**
<!-- * Configuration Overview FIXME(skullydazed/anyone): write this document -->
* [Audio](feature_audio.md)
* Lighting
* [Backlight](feature_backlight.md)
* [LED Matrix](feature_led_matrix.md)
* [RGB Lighting](feature_rgblight.md)
* [RGB Matrix](feature_rgb_matrix.md)
* [Tap-Hold Configuration](tap_hold.md)
* **Learn More About Keymaps**
* [Keymaps](keymap.md)
* [Custom Functions and Keycodes](custom_quantum_functions.md)
* Macros
* [Dynamic Macros](feature_dynamic_macros.md)
* [Compiled Macros](feature_macros.md)
* [Tap Dance](feature_tap_dance.md)
* [Combos](feature_combo.md)
* [Userspace](feature_userspace.md)
# Advanced Topics
Everything below here requires a lot of foundational knowledge. Besides being able to create keymaps using advanced features you should be familiar with using both `config.h` and `rules.mk` to configure options for your keyboard.
@@ -12,7 +12,7 @@ As of [PR#1359](https://github.com/qmk/qmk_firmware/pull/1359/), there is a new
#define PERMISSIVE_HOLD
```
This makes tap and hold keys (like Mod Tap) work better for fast typist, or for high `TAPPING_TERM` settings.
This makes tap and hold keys (like Mod Tap) work better for fast typists, or for high `TAPPING_TERM` settings.
If you press a Mod Tap key, tap another key (press and release) and then release the Mod Tap key, all within the tapping term, it will output the "tapping" function for both keys.
@@ -35,7 +35,7 @@ To enable this setting, add this to your `config.h`:
#define IGNORE_MOD_TAP_INTERRUPT
```
Similar to Permissive Hold, this alters how the firmware processes input for fast typist. If you press a Mod Tap key, press another key, release the Mod Tap key, and then release the normal key, it would normally output the "tapping" function for both keys. This may not be desirable for rolling combo keys.
Similar to Permissive Hold, this alters how the firmware processes inputs for fast typists. If you press a Mod Tap key, press another key, release the Mod Tap key, and then release the normal key, it would normally output the "tapping" function for both keys. This may not be desirable for rolling combo keys.
Setting `Ignore Mod Tap Interrupt` requires holding both keys for the `TAPPING_TERM` to trigger the hold function (the mod).
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.