* Add PS2_MOUSE_ROTATE to compensate for device orientation
* fixup! Add PS2_MOUSE_ROTATE to compensate for device orientation
* Reformat with IndentPPDirectives: AfterHash as per #6316
* Fix RGB LED count on YD60MQ
* Split YD60MQ into 12-LED and 16-LED revisions
* Update readmes
* Make 12led the default version
* Readd base rules.mk, version→variant in readme
* Add syntax highlighting to code blocks in readme
* Define NO_ACTION_MACRO/FUNCTION in header instead of makefile when LTO is enabled
Currently, boards and keymaps that define NO_ACTION_MACRO/FUNCTION unconditionally
will not compile with LTO_ENABLE (#8604). This fixes the issue by moving the
definitions from common.mk to action.h, which enables us to check for previous
definitions of those macros (this cannot be done in a makefile).
* Remove LTO checks in templates
Since now NO_ACTION_MACRO/FUNCTION are defined as needed in action.h (which is
included by quantum.h), checking for LTO in keyboard and user code is no
longer required.
* Update LTO_ENABLE docs
* enable rgblight layers
* rgblight layers code
* switch to new rgblight layers
* testing led positions
* fix caps typo
* lights and colors working
* rules updated for different rgb use
* Extra spaces removed
Without this check, users can lock themselves out by enabling developer
mode, than disabling the dependencies. They wouldn't be able to turn off
developer mode as none of the subcommands (including 'config') would
work.
The list of hidden subcommands were approved by @skullydazed ;)
Currently hidden if 'user.developer' is not True:
- cformat
- docs
- kle2json
- pyformat
- pytest
Use milc's config finding and parsing to check if the user is a
developer or not.
'requirements-dev.txt' will now load 'requirements.txt', so no need to
run pip twice.
Add missing 'yapf' dependency to 'requirements-dev.txt'.
* Change _delay_ms/us() to wait_ms/us()
* Switch to platform-agnostic GPIO macros
* Add AVR spi_master and migrate Adafruit BLE code
* Set verbose back to false
* Add clock divisor, bit order and SPI mode configuration for init
* Add start and stop functions
* Move configuration of mode, endianness and speed to `spi_start()`
* Some breaks here would be good
* Default Adafruit BLE clock divisor to 4 (2MHz on the Feather 32U4)
* Remove mode and divisor enums
* Add some docs
* No hr at EOF
* Add links in sidebar
* Selectively adding pieces
* Adding georgi keymap
* Adding more files, fixing make
* Smaller makefiles
* Fixing make rules
* README more inline with QMK's guidelines
* Turning off buggy assert
* Improving documentation based on a user feedback.
* Slightly better schema
* Resurrected state machine diagram
* updated rules.mk and default keymap of Wonderland for VIA support
* Restored default keymap and rules.mk, added via keymap folder with modified default keymap and rules.mk, also fixed VendorID in config.h
* fixed jargon on layers 3 and 4 of Wonderland VIA keymap
* cleaned up via keymap, removed fluff
* default keymap for Wonderland restored
* removed unnecessary information from rules.mk
* made more readable per noroadsleft suggestion
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Add Polish keymap
* Fix wrong AltGr mapping
* These are ogoneks, not cedillas
* Too many !s
* ANSI
* Just use BSLS
* Move BSLS
* Move PIPE
* Fix some incorrect names in keymap_slovak.h
Thanks to vomindoraan
* Add Korean keymap
* Switch to ANSI layout
* Update quantum/keymap_extras/keymap_korean.h
Co-Authored-By: Konstantin Đorđević <vomindoraan@gmail.com>
Co-authored-by: Konstantin Đorđević <vomindoraan@gmail.com>
* ADD DecadePad
* Fix Key display bug
* fix
* firmware1
THIS IS A Backup commit
* firmware2
* rename all fill with lower case
* fix bug
* Final Version
Fix all bugs
* Requested change apply
* suggested apply
* change apply
* via test
* Apply change and fix via support problem
* created initial files for the lattice60
* modifying the keymaps and config
* keymap edits and docs
* modifying docs and added personal keymap
* added pic and website to readme
* added layout image for default keymap
* updating layout pictures
* minor formatting edit
* file cleanup
* trying to prevent errors with usbconfig
* removed usbconfig.h
* cleaning up comments
* switched to use community hhkb layout
* Make initial batch of files
* Tweak keymap
* Mod default keymap
* Add via compat
* Update default keymap based on real world use
* Remove RGB, LCD, MIDI options
* Remove unnecessary functons from orbit_x.c
* Update readme
* Cleanup makefile as necessary
* Make the readme file for default keymap not completely empty
* Update keyboards/ai03/orbit_x/keymaps/default/keymap.c
* Update keyboards/ai03/orbit_x/readme.md
* Update keyboards/ai03/orbit_x/info.json
* Add VIA to Gingham
- Add VIA keymap
- Fix minor typo in config.h
- Remove redundunt methods and defines
* Update keyboards/gingham/config.h
Co-Authored-By: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* define VID/PID in post_config.h, add via keymap
* update readme, set vid/pid for via
* update keymap
* delete usbconfig.h, update keymap
* add status led feature
* Apply suggestions from code review
Co-Authored-By: Joel Challis <git@zvecr.com>
* undef vid/pid in keymap
Co-authored-by: Joel Challis <git@zvecr.com>
* add feature part 01
* update sentences
* update sentences
* update sentences
* update file based on comment
* leave ctrl, shift, alt key name as alphabet
* update file based on comment
* update file based on comment
* update file based on comment
* update file based on comment
* remove unnecessary space on define line
* update sentence based on pull request's comment
* translate 'breathing' in document
* change expression in table
* update file based on comment
* change the word 'brightness', and update based on comment
* update based on comment
* update based on comment
* add language directory name to each internal link
* update based on comment
* update based on comment
* Changes to my Ergodox & Planck keymaps
* Fixed Typos
Corrected some typos and omissions to my Ergodox layout and readme
* Fixed Typos
Fixed some typos in my ErgoDox Readme and keymap.c files
* Add Serbian keymaps and sendstring LUT
* Apply suggestions from code review
Co-Authored-By: Konstantin Đorđević <vomindoraan@gmail.com>
* Fix formatting
Co-authored-by: Konstantin Đorđević <vomindoraan@gmail.com>
* Enable External EEPROM on Planck Rev6
* Update KC_MAKE macro to use qmk cli util
* Disable additional gradients for rgb matrix
* Update analog code for newer methods
* Update ergodox layout
* Disable Grave Escape
* Cleanup OLED code a bit
* Remove old unicode code
* Seperate RGB Matrix code from RGB Light code in userspace
* Massive overhaul an generalization of personal OLED code
Now lets hope I NEVER get a keyboard using a 128x32 in a normal orientation.
* Super tiny cleanup
* Enable Diablo layer on kyria
* clang format pass
* Additional OLED cleanup
* Added via config support for the launchpad
Added via config support for the launchpad
* Update keyboards/launchpad/keymaps/via/rules.mk
Co-Authored-By: Joel Challis <git@zvecr.com>
* Update keyboards/launchpad/keymaps/via/keymap.c
Co-Authored-By: Joel Challis <git@zvecr.com>
* Update keyboards/launchpad/keymaps/via/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/launchpad/keymaps/via/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/launchpad/keymaps/via/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/launchpad/keymaps/via/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/launchpad/keymaps/via/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/launchpad/keymaps/via/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.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
* Refactoring all my keymaps.
- Not use tap dance
- Remove not use define aliases
- Remove not use incluse and extern value.
* default keymap extra key was changed
* remove rgblight_config
Co-authored-by: root <root>
* remove IT_PIPE duplicate and add IT_GRAD
IT_PIPE was declared 2 times, ones as ° and once as |. I changed the first declaration and called it IT_GRAD. I even fixed the definition because the ° in Italian is obtained with LSFT(IT_AACC)
* rename IT_GRAD to IT_DEGR
* fix missing music mode legend
* add missing plus_and_minus
* fix missing IT_ACUT definition
* change KC_LALT(KC_LSFT to LALT(LSFT
* Fix alignment
* remove leftover
* fix issue generated with chars while pushing
* fix typo
* add sigul folder in Planck keymaps
* fix LCBR and RCBR
* fix euro symbol
* fix RBRC
* change IT_LESS form KC_NUBS to KC_GRAVE
* add IT_TILDE and change IT_GRAV to IT_GRAVE
* initial commit
* add ideas to readme
* comment key lock
* add a bunch of new features as stated in readme.md
* check features added and list to do
* add macros on RAISE
* add F keys on numbers row on FN layer
* flag features added
* fix macro formulas
* move DESK and SGCOM under D and S
* invert IT_EACC and S(IT_EACC) to align the layout with that of the default Planck
* invert IT_EACC and S(IT_EACC) to align the layout with that of the default Planck
fix spaces for readability
* add missing legends for accented vowels
* format for readability
* move MOUSE button on B (same key that activates it) on MOUSE layer
* revert to commit befor I edit it
* initial commit
* edited to be easier to compare to _ansi.h
* remove keymap_italian_osx_iso.h and rename with edits keymap_italian_osx_ansi.h to keymap_italian_osx.h
I found out there were no difference at all
* fix missing #endif
* change the included file from italian.h to italian_osx.h
* fix debug key
* edit Numapd layer, add enter and bsps
* change TAPPING_TOGGLE from 2 to 3
* change italian_osx.h to italian_ansi.h
* rename quantum/keymap_extras/keymap_italian_osx.h to quantum/keymap_extras/keymap_italian_ansi.h
Now this file is a clone of the keymap_italian.h that appears to be working only for ISO keyboards. It also contains a few improvements for IT_PIPE (defined two times) and IT_ACUT (missing definition). Additionally it redefines LCBR and RCBR to LSFT(IT_LBRC) and LSFT(IT_RBRC)
* rename file
* redefines IT_BKSL and IT_PIPE based on KC_BKSL
* merge new italian
* add new osx_iso and osx_ansi version for italian.h and align BKSL to BSLS, fix double definition of PIPE
* rename BKSL to BSLS
* add FN_D and some comments
* add MOUSEKEY configuration
* update
* edit swap =/+ with ò/ì
* merge with master
* add MS_B to have _MOUSE when pressing B
* move RAISE on _FN
* add phone number
* remove CONTRA folder
* remove CONTRA folder
* Update keyboards/planck/keymaps/sigul/keymap.c
fix include definition
Co-Authored-By: Ryan <fauxpark@gmail.com>
* remove default planck kemap
* remove extern keymap_config_t keymap_config;
based on suggestion from @fauxpark, It's not needed as it should already be externed through one of the includes provided by QMK_KEYBOARD_H.
Co-Authored-By: Ryan <fauxpark@gmail.com>
* add user space for user sigul
* remove custom config moved to user space sigul
* comment tri layers state (moved to user space)
* remove tri layers update comment (code moved in user space)
* add secrets
* move enum and define to userspace
* Edit title
* move enum and define to sigul.h
* add thanks
* edit: moving to userspace enum, define and process_records
* add enum and defines
* add process_records
* cleaning code after moving code to user space
* add process_records
* cleaning code
* adding rules to manage secrets
* remove secretes
* first commit
* add macro timer
* add keycodes macro
* edit custom keycodes order
* add strings to send inside the secrets array
* remove codes for secrets & change secret to secrets
* edit secrets keycodes
* edit keycodes names and order
* add secrets.h and secrets.c
* add #pragma once
Co-Authored-By: Joel Challis <git@zvecr.com>
* Update .gitignore
Co-Authored-By: Joel Challis <git@zvecr.com>
* add local gitignore for secrets
* remove secrets
* update for secrets
* change FN_D to IT_D
* remove FN_D definition
Co-authored-by: pisilvio <silvio@picampus.it>
Co-authored-by: admin <admin@admins-MacBook-Pro.local>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* Rename UC_OSX (and related constants) to UC_MAC
* Update UNICODE_SONG_OSX references to UNICODE_SONG_MAC
* Update UC_M_OS references to UC_M_MA
* Add UC_OSX alias for backwards compatibility
* Add deprecation warning for UC_OSX to Unicode docs
* Add UC_M_OS alias for backwards compatibility
* Update newly found UC_M_OS and UNICODE_SONG_OSX references
* Add legacy UNICODE_MODE_OSX alias, revert changes to user keymaps
* Add legacy UNICODE_SONG_OSX alias, revert changes to user keymaps
* Replace removed sounds in Unicode song doc examples
* rewrite usbhid feature on vusb
* Apply suggestions from code review
Co-Authored-By: Ryan <fauxpark@gmail.com>
* fix typo
* fix typo again
* Update tmk_core/protocol/vusb/vusb.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* clean up defines
Co-authored-by: Ryan <fauxpark@gmail.com>
* Change PID to allow differentiation between Rev. 3 and Rev. 4
* Rebadge thumb keys in macro to show physical wiring better
* Add more rules for VIA keymap
* added the description of the reading order of the rules.mk files.
* Update docs/hardware_keyboard_guidelines.md
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update docs/hardware_keyboard_guidelines.md
Co-Authored-By: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* CLI: More MSYS2 fixes
Now I can fully setup and work with qmk_firmware on an MSYS2
installation without any errors or exceptions.
* Apply suggestions from code review
Co-Authored-By: skullydazed <skullydazed@users.noreply.github.com>
* Some improvements
* Remove unnecessary import
* Remove slow, unused code
Getting the version from GIT was slow on both Windows and Docker.
Until we find a better, faster way, this is removed.
* remove unused imports
* Implement @vomindoraan's suggestions
* refine how we pick the shell to use
* Apply @fauxpark's suggestions
fauxpark investigated the topic of shells in MSYS2 a bit and we come to the conclusion that the safest bet was to just use the user's shell.
Anything more just opens up more edge-cases than it solves.
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Use `platform_id` in doctor
This will bring it in line with the new code.
Co-authored-by: skullydazed <skullydazed@users.noreply.github.com>
Co-authored-by: skullY <skullydazed@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update tmk_core/common/progmem.h
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update quantum/rgblight.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* fixed problem with implicit declaration in quantum/rgblight.c (#8381)
Co-authored-by: Ryan <fauxpark@gmail.com>
* convert my 60 keymap to alice
* add via to rules for alice
* remove split backspace and add backlight keycodes
* disable LTO for alice pcb
* keymap alignment formatting
* initial commit
* preliminary support for mb17 using the qmk default keymap
* add the VIA keymap
* add qmk configurator support
* code cleanups before submission
* Update keyboards/mountainblocks/mb17/rules.mk
* Update keyboards/mountainblocks/mb17/info.json
* remove file
* Port over some AVR backlight logic to SLEEP_LED
* Port over some AVR backlight logic to SLEEP_LED - add timer 3
* Port over some AVR backlight logic to SLEEP_LED - clang format
* Enable SLEEP_LED within vusb protocol
* Add support for RAW endpoint for arm_atsam
This the excellent work from helluvamatt/qmk_firmware in bb6eeb93b.
* Reformat arm_atsam RAW endpoint code
Co-authored-by: Matt Schneeberger <helluvamatt@gmail.com>
* add new layout for 65% with blocker and add matching keymap
the rev2 pcb gets used in the kbd67 which has a blocker between the left arrow key and the right ctrl key. this layout is missing so far even though it's probably the most used one for this board.
* add split backspace layout with blocker
* change keycode for backslash
* update rules.mk and add missing layouts in info.json
* Update keyboards/kbdfans/kbd67/rev2/rules.mk
Co-Authored-By: Joel Challis <git@zvecr.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* [Docs] Update RGB Matrix docs with function refs
* Fix up code samples
* suggestions by noroadsleft
* Fix small typo
Co-authored-by: James Young <xxiinophobia@yahoo.com>
* Add Kudox Game rev2.
* Add the keymap of Kudox Game a layer for regulating RGB.
* Modified rgblight_init when RGBLIGHT_ENABLE=no.
* Remove invalid codes.
* Modified *init* function right intention of framework.
* Set backlight and RGB pins for AVR onekeys
* Set pin for ADC as well
* Define ADC_PIN for F4 blackpills
* Use A0 for F4 ADCs
* Set ADC pins for F0 and F1
* [Keymap] Minidox Bepo layout
Todo :
Lower
Adjust
Update Lower E and Lower S on schema
* Added config.h
* Code review, update config.h
Co-Authored-By: Ryan <fauxpark@gmail.com>
Co-authored-by: dolie <olivier.ghafari@pm.me>
Co-authored-by: Ryan <fauxpark@gmail.com>
* First cut at Josh Diamond's KBD75 customizations.
Includes:
* My unique keymap with ChromeOS specific keys
* Use RGB underglow to indicate Caps Lock
* Some unicode bindings
* Some changes to make debugging easier
* Updated spidey3 to be applicable to all 75_ansi boards
* Sadly, ChromeOS doesn't pay attention to most consumer codes
* Add mac layer; fix flakeyness in CAPS_LOCK underglow.
* Make layers.json match the keymap (to the extent possible)
* Major cleanup; fix broken debug persistence
* Cleanup some whitespace issues
* Fix incorrect log message.
* Rework layer indication to user RGBLIGHT_LAYERS
* Update layouts/community/75_ansi/spidey3/keymap.c
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Rename users/spidey3/rgblight.c to layer_rgb.c per suggestion
* Refactor to use set_single_persistant_default_layer().
* Use dprint/f to make logging more elegant.
* Update users/spidey3/config.h
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Update users/spidey3/config.h
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Update layouts/community/75_ansi/spidey3/rules.mk
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update users/spidey3/spidey3.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update users/spidey3/layer_rgb.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update users/spidey3/init.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Changes from code review
Co-authored-by: Joshua Diamond <jdiamond@Deep-Thought.local>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Improve process_record system
Code based on @colinta's
* Rename and better handle functions
* Fix incorrect function call to process_record_user
* Add documentation for post_process_record
* Add both get_event_keycode and get_record_keycode functions
And add some comments about these functions
* Update code format
* Cleanup merge artifacts
* Add Word Per Minute calculation feature
* Fix copyright info
* Remove header from quantum.c, setup overloadable keycode inclusion for WPM, update docs
* Simplify logic for keycode filtering
* Adding link from summary to wpm_feature info
* Update docs/feature_wpm.md
Typo in function prototype example in docs
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
* Add WPM transport via i2c
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Reorder logic within common_features.mk
* Revert haptic logic
* Add back path to make tests happy
* Update common_features.mk
Co-Authored-By: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add support for Bootmagic lite when using SPLIT_HAND_PIN
* Deduplicate bootmagic_lite logic from within via
* Revert location of defaults so that user overrides still work for now
* Tidy up code slightly
* Lodestone: add ANSI and ISO layout data and keymaps
* rename layout macros
LAYOUT_ansi -> LAYOUT_65_ansi_blocker_split_bs
LAYOUT_iso -> LAYOUT_65_iso_blocker_split_bs
* use four-space indent on the new keymaps
* add 65_ansi_blocker and 65_iso_blocker layouts
* [Docs] Update layer documentation
* Add layer_state_cmp functions
* Fix cut/copy/paste issue
* Add id tags
* Apply noroads corrections
* Move Layers section to separate document
* Fix ID tag for layers
* Use better name for summary/side bar
* Fix feature page linkage
As well as a small spell error close by
* Remove paper analogy for now
* VIA Support: GH60 Rev C and GH60 Satan
* Corrected GH60 VIA default keymap
* Corrected GH60 VIA default keymap pt 2
* Copied default keymap over via default keymap
* Satan GH60 default corrected for VIA
* Satan GH60 default corrected for VIA pt 2
* Satan GH60 LTO enable for size
* Transparent 4th dynamic layer for GH60 Via support
* Update keyboards/gh60/revc/info.json
* Update keyboards/gh60/satan/info.json
* Update keyboards/gh60/satan/info.json
* Removed deprecated JSON keys gh60/revc/info.json
* Removed inline comment next to VID for GH60 Satan
* add via support for pdxkbc macropad
* add VIA support for the pdxkbc
* clean out some commented code
* remove unused files
* comment the vendor ID
* Update keyboards/pdxkbc/keymaps/via/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/pdxkbc/keymaps/via/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/pdxkbc/keymaps/via/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/pdxkbc/keymaps/via/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/pdxkbc/keymaps/via/keymap.c
Co-Authored-By: Joel Challis <git@zvecr.com>
* Update keyboards/pdxkbc/keymaps/via/keymap.c
Co-Authored-By: Joel Challis <git@zvecr.com>
* Update keyboards/pdxkbc/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>
* Create rules.mk
Added rules.mk in keymaps/via
* Update rules.mk
Added new line at the end of the file
* Create via\keymap.c
Added keymap.c inside the via directory
* Update config.h in projectkb/alice
Defined VIA eeprom layout size to 2 bits to allow for 4 layout options
* Add Lodestone PCB
Working Firmware for Lodestone PCB tested on physical PCB prototypes.
* Update keyboards/flx/lodestone/lodestone.c
* Update keyboards/flx/lodestone/keymaps/default/config.h
* Update keyboards/flx/lodestone/rules.mk
* Update keyboards/flx/lodestone/readme.md
* Delete config.h
* Update keyboards/flx/lodestone/info.json
Suggested by noroadsleft
* Update keyboards/flx/lodestone/info.json
* Update keyboards/flx/lodestone/info.json
Changed maintainer name as suggested.
* Update keyboards/flx/lodestone/keymaps/default/readme.md
* Update keyboards/flx/lodestone/info.json
* Update keyboards/flx/lodestone/rules.mk
Changed Link_Time_Optimization to LTO didn't know this was a thing :)
* Update keyboards/flx/lodestone/keymaps/default/keymap.c
Removed 2 unessisary layers from the default map.
* Update keyboards/flx/lodestone/readme.md
* Update keyboards/flx/lodestone/info.json
* Changed from LAYOUT to LAYOUT_all
AS suggested by noroadsleft, changed 4 files to match, and re-testeed on my hardware to confirm working.
* Update keyboards/flx/lodestone/config.h
Cleaned up Manu, Product and Descriptor as suggested.
* Update keyboards/flx/lodestone/readme.md
* Assign unique VID to LazyDesigners' boards
* Add VIA support for LazyDesigners Dimple
* Apply @fauxpark's suggestions
Co-Authored-By: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update switch to array to allow custom values
* Add adc keymap
* update docs to reflect alignment of default 10 bit
* start conversion to USE_ADCVn
* samplerate is hella wrong...stub out for now
* basic f1 and f4 functionality
* Tidy up current changes
* Restore old pinToMux function
* Add back sample rate for supported platforms
* F0 compile fixes
* wordsmithery
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Remove reference to avr only function
Co-authored-by: Ryan <fauxpark@gmail.com>
QMK can leverage the Analog-to-Digital Converter (ADC) on supported MCUs to measure voltages on certain pins. This can be useful for implementing things such as battery level indicators for Bluetooth keyboards, or volume controls using a potentiometer, as opposed to a [rotary encoder](feature_encoders.md).
This driver currently supports both AVR and a limited selection of ARM devices. On AVR devices, the values returned are 10-bit integers (0-1023) mapped between 0V and VCC (usually 5V or 3.3V). On supported ARM devices, there is more flexibility in control of operation through `#define`s, but by default the values returned are 12-bit integers (0-4095) mapped between 0V and VCC (usually 3.3V).
This driver currently supports both AVR and a limited selection of ARM devices. The values returned are 10-bit integers (0-1023) mapped between 0V and VCC (usually 5V or 3.3V for AVR, 3.3V only for ARM), however on ARM there is more flexibility in control of operation through `#define`s if you need more precision.
Run it with no arguments to format all core code that has been changed. Default checks `origin/master` with `git diff`, branch can be changed using `-b <branch_name>`
Run it with `-a` to format all core code, or pass filenames on the command line to run it on specific files.
**Usage for specified files**:
```
qmk cformat [file1] [file2] [...] [fileN]
```
**Usage for all core files**:
```
qmk cformat -a
```
**Usage for only changed files against origin/master**:
```
qmk cformat
```
**Usage for only changed files against branch_name**:
```
qmk cformat -b branch_name
```
# User Commands
## `qmk compile`
@ -136,16 +104,6 @@ This command lets you configure the behavior of QMK. For the full `qmk config` d
This command starts a local HTTP server which you can use for browsing or improving the docs. Default port is 8936.
**Usage**:
```
qmk docs [-p PORT]
```
## `qmk doctor`
This command examines your environment and alerts you to potential build or flash problems. It can fix many of them if you want it to.
@ -180,28 +138,6 @@ Creates a keymap.c from a QMK Configurator export.
qmk json2c [-o OUTPUT] filename
```
## `qmk kle2json`
This command allows you to convert from raw KLE data to QMK Configurator JSON. It accepts either an absolute file path, or a file name in the current directory. By default it will not overwrite `info.json` if it is already present. Use the `-f` or `--force` flag to overwrite.
**Usage**:
```
qmk kle2json [-f] <filename>
```
**Examples**:
```
$ qmk kle2json kle.txt
☒ File info.json already exists, use -f or --force to overwrite.
```
```
$ qmk kle2json -f kle.txt -f
Ψ Wrote out to info.json
```
## `qmk list-keyboards`
This command lists all the keyboards currently defined in `qmk_firmware`
@ -232,6 +168,74 @@ This command creates a new keymap based on a keyboard's existing default keymap.
qmk new-keymap [-kb KEYBOARD] [-km KEYMAP]
```
---
# Developer Commands
## `qmk cformat`
This command formats C code using clang-format.
Run it with no arguments to format all core code that has been changed. Default checks `origin/master` with `git diff`, branch can be changed using `-b <branch_name>`
Run it with `-a` to format all core code, or pass filenames on the command line to run it on specific files.
**Usage for specified files**:
```
qmk cformat [file1] [file2] [...] [fileN]
```
**Usage for all core files**:
```
qmk cformat -a
```
**Usage for only changed files against origin/master**:
```
qmk cformat
```
**Usage for only changed files against branch_name**:
```
qmk cformat -b branch_name
```
## `qmk docs`
This command starts a local HTTP server which you can use for browsing or improving the docs. Default port is 8936.
**Usage**:
```
qmk docs [-p PORT]
```
## `qmk kle2json`
This command allows you to convert from raw KLE data to QMK Configurator JSON. It accepts either an absolute file path, or a file name in the current directory. By default it will not overwrite `info.json` if it is already present. Use the `-f` or `--force` flag to overwrite.
**Usage**:
```
qmk kle2json [-f] <filename>
```
**Examples**:
```
$ qmk kle2json kle.txt
☒ File info.json already exists, use -f or --force to overwrite.
```
```
$ qmk kle2json -f kle.txt -f
Ψ Wrote out to info.json
```
## `qmk pyformat`
This command formats python code in `qmk_firmware`.
@ -251,3 +255,4 @@ This command runs the python test suite. If you make changes to python code you
@ -6,6 +6,18 @@ This document has useful information for developers wishing to write new `qmk` s
The QMK CLI operates using the subcommand pattern made famous by git. The main `qmk` script is simply there to setup the environment and pick the correct entrypoint to run. Each subcommand is a self-contained module with an entrypoint (decorated by `@cli.subcommand()`) that performs some action and returns a shell returncode, or None.
## Developer mode:
If you intend to maintain keyboards and/or contribute to QMK, you can enable the CLI's "Developer" mode:
`qmk config user.developer=True`
This will allow you to see all available subcommands.
**Note:** You will have to install additional requirements:
```bash
python3 -m pip install -r requirements-dev.txt
```
# Subcommands
[MILC](https://github.com/clueboard/milc) is the CLI framework `qmk` uses to handle argument parsing, configuration, logging, and many other features. It lets you focus on writing your tool without wasting your time writing glue code.
@ -20,11 +20,11 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
* We accept both forms of preprocessor if's: `#ifdef DEFINED` and `#if defined(DEFINED)`
* If you are not sure which to prefer use the `#if defined(DEFINED)` form.
* Do not change existing code from one style to the other, except when moving to a multiple condition `#if`.
*Do not put whitespace between `#` and `if`.
*When deciding how (or if) to indent directives keep these points in mind:
*Readability is more important than consistency.
*Follow the file's existing style. If the file is mixed follow the style that makes sense for the section you are modifying.
*When choosing to indent you can follow the indention level of the surrounding C code, or preprocessor directives can have their own indent level. Choose the style that best communicates the intent of your code.
*When deciding how (or if) to indent preprocessor directives, keep these points in mind:
*Readability is more important than consistency.
*Follow the file's existing style. If the file is mixed, follow the style that makes sense for the section you are modifying.
*When indenting, keep the hash at the start of the line and add whitespace between `#` and `if`, starting with 4 spaces after the `#`.
*You can follow the indention level of the surrounding C code, or preprocessor directives can have their own indentation levels. Choose the style that best communicates the intent of your code.
* disable old-style macro handling using `MACRO()`, `action_get_macro()`_(deprecated)_
*`#define NO_ACTION_FUNCTION`
* disable calling of action_function() from the fn_actions array (deprecated)
* disable old-style function handling using `fn_actions`, `action_function()`_(deprecated)_
## Features That Can Be Enabled
@ -317,10 +317,10 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i
* `LAYOUTS`
* A list of [layouts](feature_layouts.md) this keyboard supports.
* `LINK_TIME_OPTIMIZATION_ENABLE`
* Enables Link Time Optimization (`LTO`) when compiling the keyboard. This makes the process take longer, but can significantly reduce the compiled size (and since the firmware is small, the added time is not noticeable). However, this will automatically disable the old Macros and Functions features automatically, as these break when `LTO` is enabled.
It does this by automatically defining `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION`
* Enables Link Time Optimization (LTO) when compiling the keyboard. This makes the process take longer, but it can significantly reduce the compiled size (and since the firmware is small, the added time is not noticeable).
However, this will automatically disable the legacy TMK Macros and Functions features, as these break when LTO is enabled. It does this by automatically defining `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION`. (Note: This does not affect QMK [Macros](feature_macros.md) and [Layers](feature_layers.md).)
* `LTO_ENABLE`
* It has the same meaning as LINK_TIME_OPTIMIZATION_ENABLE. You can use `LTO_ENABLE` instead of `LINK_TIME_OPTIMIZATION_ENABLE`.
* Has the same meaning as `LINK_TIME_OPTIMIZATION_ENABLE`. You can use `LTO_ENABLE` instead of `LINK_TIME_OPTIMIZATION_ENABLE`.
# Switching and Toggling Layers :id=switching-and-toggling-layers
These functions allow you to activate layers in various ways. Note that layers are not generally independent layouts -- multiple layers can be activated at once, and it's typical for layers to use `KC_TRNS` to allow keypresses to pass through to lower layers. For a detailed explanation of layers, see [Keymap Overview](keymap.md#keymap-and-layers). When using momentary layer switching with MO(), LM(), TT(), or LT(), make sure to leave the key on the above layers transparent or it may not work as intended.
*`DF(layer)` - switches the default layer. The default layer is the always-active base layer that other layers stack on top of. See below for more about the default layer. This might be used to switch from QWERTY to Dvorak layout. (Note that this is a temporary switch that only persists until the keyboard loses power. To modify the default layer in a persistent way requires deeper customization, such as calling the `set_single_persistent_default_layer` function inside of [process_record_user](custom_quantum_functions.md#programming-the-behavior-of-any-keycode).)
*`MO(layer)` - momentarily activates *layer*. As soon as you let go of the key, the layer is deactivated.
*`LM(layer, mod)` - Momentarily activates *layer* (like `MO`), but with modifier(s) *mod* active. Only supports layers 0-15 and the left modifiers: `MOD_LCTL`, `MOD_LSFT`, `MOD_LALT`, `MOD_LGUI` (note the use of `MOD_` constants instead of `KC_`). These modifiers can be combined using bitwise OR, e.g. `LM(_RAISE, MOD_LCTL | MOD_LALT)`.
*`LT(layer, kc)` - momentarily activates *layer* when held, and sends *kc* when tapped. Only supports layers 0-15.
*`OSL(layer)` - momentarily activates *layer* until the next key is pressed. See [One Shot Keys](one_shot_keys.md) for details and additional functionality.
*`TG(layer)` - toggles *layer*, activating it if it's inactive and vice versa
*`TO(layer)` - activates *layer* and de-activates all other layers (except your default layer). This function is special, because instead of just adding/removing one layer to your active layer stack, it will completely replace your current active layers, uniquely allowing you to replace higher layers with a lower one. This is activated on keydown (as soon as the key is pressed).
*`TT(layer)` - Layer Tap-Toggle. If you hold the key down, *layer* is activated, and then is de-activated when you let go (like `MO`). If you repeatedly tap it, the layer will be toggled on or off (like `TG`). It needs 5 taps by default, but you can change this by defining `TAPPING_TOGGLE` -- for example, `#define TAPPING_TOGGLE 2` to toggle on just two taps.
## Caveats
Currently, `LT()` and `MT()` are limited to the [Basic Keycode set](keycodes_basic.md), meaning you can't use keycodes like `LCTL()`, `KC_TILD`, or anything greater than `0xFF`. Modifiers specified as part of a Layer Tap or Mod Tap's keycode will be ignored. If you need to apply modifiers to your tapped keycode, [Tap Dance](feature_tap_dance.md#example-5-using-tap-dance-for-advanced-mod-tap-and-layer-tap-keys) can be used to accomplish this.
Additionally, if at least one right-handed modifier is specified in a Mod Tap or Layer Tap, it will cause all modifiers specified to become right-handed, so it is not possible to mix and match the two.
# Working with Layers
Care must be taken when switching layers, it's possible to lock yourself into a layer with no way to deactivate that layer (without unplugging your keyboard.) We've created some guidelines to help users avoid the most common problems.
## Beginners
If you are just getting started with QMK you will want to keep everything simple. Follow these guidelines when setting up your layers:
* Setup layer 0 as your default, "base" layer. This is your normal typing layer, and could be whatever layout you want (qwerty, dvorak, colemak, etc.). It's important to set this as the lowest layer since it will typically have most or all of the keyboard's keys defined, so would block other layers from having any effect if it were above them (i.e., had a higher layer number).
* Arrange your layers in a "tree" layout, with layer 0 as the root. Do not try to enter the same layer from more than one other layer.
* In a layer's keymap, only reference higher-numbered layers. Because layers are processed from the highest-numbered (topmost) active layer down, modifying the state of lower layers can be tricky and error-prone.
## Intermediate Users
Sometimes you need more than one base layer. For example, if you want to switch between QWERTY and Dvorak, switch between layouts for different countries, or switch your layout for different videogames. Your base layers should always be the lowest numbered layers. When you have multiple base layers you should always treat them as mutually exclusive. When one base layer is on the others are off.
## Advanced Users
Once you have a good feel for how layers work and what you can do, you can get more creative. The rules listed in the beginner section will help you be successful by avoiding some of the tricker details but they can be constraining, especially for ultra-compact keyboard users. Understanding how layers work will allow you to use them in more advanced ways.
Layers stack on top of each other in numerical order. When determining what a keypress does, QMK scans the layers from the top down, stopping when it reaches the first active layer that is not set to `KC_TRNS`. As a result if you activate a layer that is numerically lower than your current layer, and your current layer (or another layer that is active and higher than your target layer) has something other than `KC_TRNS`, that is the key that will be sent, not the key on the layer you just activated. This is the cause of most people's "why doesn't my layer get switched" problem.
Sometimes, you might want to switch between layers in a macro or as part of a tap dance routine. `layer_on` activates a layer, and `layer_off` deactivates it. More layer-related functions can be found in [action_layer.h](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/common/action_layer.h).
# Modifier Keys :id=modifier-keys
These allow you to combine a modifier with a keycode. When pressed, the keydown event for the modifier, then `kc` will be sent. On release, the keyup event for `kc`, then the modifier will be sent.
@ -63,10 +20,14 @@ These allow you to combine a modifier with a keycode. When pressed, the keydown
You can also chain them, for example `LCTL(LALT(KC_DEL))` makes a key that sends Control+Alt+Delete with a single keypress.
# Legacy Content
# Legacy Content :id=legacy-content
This page used to encompass a large set of features. We have moved many sections that used to be part of this page to their own pages. Everything below this point is simply a redirect so that people following old links on the web find what they're looking for.
@ -123,7 +123,7 @@ If you would like to change the hotkey assignments for Bootmagic, `#define` thes
# Bootmagic Lite :id=bootmagic-lite
In addition to the full blown Bootmagic feature, is the Bootmagic Lite feature that only handles jumping into the bootloader. This is great for boards that don't have a physical reset button but you need a way to jump into the bootloader, and don't want to deal with the headache that Bootmagic can cause.
In addition to the full blown Bootmagic feature, is the Bootmagic Lite feature that only handles jumping into the bootloader. This is great for boards that don't have a physical reset button but you need a way to jump into the bootloader, and don't want to deal with the headache that Bootmagic can cause.
To enable this version of Bootmagic, you need to enable it in your `rules.mk` with:
@ -131,7 +131,7 @@ To enable this version of Bootmagic, you need to enable it in your `rules.mk` wi
BOOTMAGIC_ENABLE= lite
```
Additionally, you may want to specify which key to use. This is especially useful for keyboards that have unusual matrices. To do so, you need to specify the row and column of the key that you want to use. Add these entries to your `config.h` file:
Additionally, you may want to specify which key to use. This is especially useful for keyboards that have unusual matrices. To do so, you need to specify the row and column of the key that you want to use. Add these entries to your `config.h` file:
```c
#define BOOTMAGIC_LITE_ROW 0
@ -144,9 +144,20 @@ And to trigger the bootloader, you hold this key down when plugging the keyboard
!> Using bootmagic lite will **always reset** the EEPROM, so you will lose any settings that have been saved.
## Split Keyboards
When handedness is predetermined via an option like `SPLIT_HAND_PIN`, you might need to configure a different key between halves. This To do so, add these entries to your `config.h` file:
```c
#define BOOTMAGIC_LITE_ROW_RIGHT 4
#define BOOTMAGIC_LITE_COLUMN_RIGHT 1
```
By default, these values are not set.
## Advanced Bootmagic Lite
The `bootmagic_lite` function is defined weakly, so that you can replace this in your code, if you need. A great example of this is the Zeal60 boards that have some additional handling needed.
The `bootmagic_lite` function is defined weakly, so that you can replace this in your code, if you need. A great example of this is the Zeal60 boards that have some additional handling needed.
To replace the function, all you need to do is add something like this to your code:
@ -163,4 +174,4 @@ void bootmagic_lite(void) {
}
```
You can additional feature here. For instance, resetting the eeprom or requiring additional keys to be pressed to trigger bootmagic. Keep in mind that `bootmagic_lite` is called before a majority of features are initialized in the firmware.
You can additional feature here. For instance, resetting the eeprom or requiring additional keys to be pressed to trigger bootmagic. Keep in mind that `bootmagic_lite` is called before a majority of features are initialized in the firmware.
One of the most powerful and well used features of QMK Firmware is the ability to use layers. For most people, this amounts to a function key that allows for different keys, much like what you would see on a laptop or tablet keyboard.
For a detailed explanation of how the layer stack works, checkout [Keymap Overview](keymap.md#keymap-and-layers).
## Switching and Toggling Layers :id=switching-and-toggling-layers
These functions allow you to activate layers in various ways. Note that layers are not generally independent layouts -- multiple layers can be activated at once, and it's typical for layers to use `KC_TRNS` to allow keypresses to pass through to lower layers. When using momentary layer switching with MO(), LM(), TT(), or LT(), make sure to leave the key on the above layers transparent or it may not work as intended.
*`DF(layer)` - switches the default layer. The default layer is the always-active base layer that other layers stack on top of. See below for more about the default layer. This might be used to switch from QWERTY to Dvorak layout. (Note that this is a temporary switch that only persists until the keyboard loses power. To modify the default layer in a persistent way requires deeper customization, such as calling the `set_single_persistent_default_layer` function inside of [process_record_user](custom_quantum_functions.md#programming-the-behavior-of-any-keycode).)
*`MO(layer)` - momentarily activates *layer*. As soon as you let go of the key, the layer is deactivated.
*`LM(layer, mod)` - Momentarily activates *layer* (like `MO`), but with modifier(s) *mod* active. Only supports layers 0-15 and the left modifiers: `MOD_LCTL`, `MOD_LSFT`, `MOD_LALT`, `MOD_LGUI` (note the use of `MOD_` constants instead of `KC_`). These modifiers can be combined using bitwise OR, e.g. `LM(_RAISE, MOD_LCTL | MOD_LALT)`.
*`LT(layer, kc)` - momentarily activates *layer* when held, and sends *kc* when tapped. Only supports layers 0-15.
*`OSL(layer)` - momentarily activates *layer* until the next key is pressed. See [One Shot Keys](one_shot_keys.md) for details and additional functionality.
*`TG(layer)` - toggles *layer*, activating it if it's inactive and vice versa
*`TO(layer)` - activates *layer* and de-activates all other layers (except your default layer). This function is special, because instead of just adding/removing one layer to your active layer stack, it will completely replace your current active layers, uniquely allowing you to replace higher layers with a lower one. This is activated on keydown (as soon as the key is pressed).
*`TT(layer)` - Layer Tap-Toggle. If you hold the key down, *layer* is activated, and then is de-activated when you let go (like `MO`). If you repeatedly tap it, the layer will be toggled on or off (like `TG`). It needs 5 taps by default, but you can change this by defining `TAPPING_TOGGLE` -- for example, `#define TAPPING_TOGGLE 2` to toggle on just two taps.
### Caveats :id=caveats
Currently, `LT()` and `MT()` are limited to the [Basic Keycode set](keycodes_basic.md), meaning you can't use keycodes like `LCTL()`, `KC_TILD`, or anything greater than `0xFF`. Specifically, dual function keys like `LT` and `MT` use a 16 bit keycode. 4 bits are used for the function identifier, the next 12 are divided into the parameters. Layer Tap uses 4 bits for the layer (and is why it's limited to layers 0-16, actually), while Mod Tap does the same, 4 bits for the identifier, 4 bits for which mods are used, and all of them use 8 bits for the keycode. Because of this, the keycode used is limited to `0xFF` (0-255), which are the basic keycodes only.
Expanding this would be complicated, at best. Moving to a 32-bit keycode would solve a lot of this, but would double the amount of space that the keymap matrix uses. And it could potentially cause issues, too. If you need to apply modifiers to your tapped keycode, [Tap Dance](feature_tap_dance.md#example-5-using-tap-dance-for-advanced-mod-tap-and-layer-tap-keys) can be used to accomplish this.
Additionally, if at least one right-handed modifier is specified in a Mod Tap or Layer Tap, it will cause all modifiers specified to become right-handed, so it is not possible to mix and match the two.
## Working with Layers :id=working-with-layers
Care must be taken when switching layers, it's possible to lock yourself into a layer with no way to deactivate that layer (without unplugging your keyboard.) We've created some guidelines to help users avoid the most common problems.
### Beginners :id=beginners
If you are just getting started with QMK you will want to keep everything simple. Follow these guidelines when setting up your layers:
* Setup layer 0 as your default, "base" layer. This is your normal typing layer, and could be whatever layout you want (qwerty, dvorak, colemak, etc.). It's important to set this as the lowest layer since it will typically have most or all of the keyboard's keys defined, so would block other layers from having any effect if it were above them (i.e., had a higher layer number).
* Arrange your layers in a "tree" layout, with layer 0 as the root. Do not try to enter the same layer from more than one other layer.
* In a layer's keymap, only reference higher-numbered layers. Because layers are processed from the highest-numbered (topmost) active layer down, modifying the state of lower layers can be tricky and error-prone.
### Intermediate Users :id=intermediate-users
Sometimes you need more than one base layer. For example, if you want to switch between QWERTY and Dvorak, switch between layouts for different countries, or switch your layout for different videogames. Your base layers should always be the lowest numbered layers. When you have multiple base layers you should always treat them as mutually exclusive. When one base layer is on the others are off.
### Advanced Users :id=advanced-users
Once you have a good feel for how layers work and what you can do, you can get more creative. The rules listed in the beginner section will help you be successful by avoiding some of the tricker details but they can be constraining, especially for ultra-compact keyboard users. Understanding how layers work will allow you to use them in more advanced ways.
Layers stack on top of each other in numerical order. When determining what a keypress does, QMK scans the layers from the top down, stopping when it reaches the first active layer that is not set to `KC_TRNS`. As a result if you activate a layer that is numerically lower than your current layer, and your current layer (or another layer that is active and higher than your target layer) has something other than `KC_TRNS`, that is the key that will be sent, not the key on the layer you just activated. This is the cause of most people's "why doesn't my layer get switched" problem.
Sometimes, you might want to switch between layers in a macro or as part of a tap dance routine. `layer_on` activates a layer, and `layer_off` deactivates it. More layer-related functions can be found in [action_layer.h](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/common/action_layer.h).
## Functions :id=functions
There are a number of functions (and variables) related to how you can use or manipulate the layers.
| `layer_state_set(layer_mask)` | Directly sets the layer state (recommended, do not use unless you know what you are doing). |
| `layer_clear()` | Clears all layers (turns them all off). |
| `layer_move(layer)` | Turns specified layer on, and all other layers off. |
| `layer_on(layer)` | Turns specified layer on, leaves all other layers in existing state. |
| `layer_off(layer)` | Turns specified layer off, leaves all other layers in existing state. |
| `layer_invert(layer)` | Interverts/toggles the state of the specified layer |
| `layer_or(layer_mask)` | Turns on layers based on matching bits between specifed layer and existing layer state. |
| `layer_and(layer_mask)` | Turns on layers based on matching enabled bits between specifed layer and existing layer state. |
| `layer_xor(layer_mask)` | Turns on layers based on non-matching bits between specifed layer and existing layer state. |
| `layer_debug(layer_mask)` | Prints out the current bit mask and highest active layer to debugger console. |
| `default_layer_set(layer_mask)` | Directly sets the default layer state (recommended, do not use unless you know what you are doing). |
| `default_layer_or(layer_mask)` | Turns on layers based on matching bits between specifed layer and existing default layer state. |
| `default_layer_and(layer_mask)` | Turns on layers based on matching enabled bits between specifed layer and existing default layer state. |
| `default_layer_xor(layer_mask)` | Turns on layers based on non-matching bits between specifed layer and existing default layer state. |
| `default_layer_debug(layer_mask)` | Prints out the current bit mask and highest active default layer to debugger console. |
| [`set_single_persistent_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer) | Sets the default layer and writes it to persistent memory (EEPROM). |
| [`update_tri_layer(x, y, z)`](ref_functions.md#update_tri_layerx-y-z) | Checks if layers `x` and `y` are both on, and sets `z` based on that (on if both on, otherwise off). |
| [`update_tri_layer_state(state, x, y, z)`](ref_functions.md#update_tri_layer_statestate-x-y-z) | Does the same as `update_tri_layer(x, y, z)`, but from `layer_state_set_*` functions. |
In additional to the functions that you can call, there are a number of callback functions that get called every time the layer changes. This passed the layer state to the function, which can be read or modified.
| `layer_state_set_kb(layer_state_t state)` | Callback for layer functions, for keyboard. |
| `layer_state_set_user(layer_state_t state)` | Callback for layer functions, for users. |
| `default_layer_state_set_kb(layer_state_t state)` | Callback for default layer functions, for keyboard. Called on keyboard initialization. |
| `default_layer_state_set_user(layer_state_t state)` | Callback for default layer functions, for users. Called on keyboard initialization. |
?> For additional details on how you can use these callbacks, check out the [Layer Change Code](custom_quantum_functions.md#layer-change-code) document.
| `layer_state_cmp(cmp_layer_state, layer)` | This checks the `cmp_layer_state` to see if the specific `layer` is enabled. This is meant for use with the layer callbacks. |
| `layer_state_is(layer)` | This checks the layer state to see if the specific `layer` is enabled. (calls `layer_state_cmp` for the global layer state). |
!> There is `IS_LAYER_ON(layer)` as well, however the `layer_state_cmp` function has some additional handling to ensure that on layer 0 that it returns the correct value. Otherwise, if you check to see if layer 0 is on, you may get an incorrect value returned.
By default, the Leader Key feature will filter the keycode out of [`Mod-Tap`](mod_tap.md) and [`Layer Tap`](feature_advanced_keycodes.md#switching-and-toggling-layers) functions when checking for the Leader sequences. That means if you're using `LT(3, KC_A)`, it will pick this up as `KC_A` for the sequence, rather than `LT(3, KC_A)`, giving a more expected behavior for newer users.
By default, the Leader Key feature will filter the keycode out of [`Mod-Tap`](mod_tap.md) and [`Layer Tap`](feature_layers.md#switching-and-toggling-layers) functions when checking for the Leader sequences. That means if you're using `LT(3, KC_A)`, it will pick this up as `KC_A` for the sequence, rather than `LT(3, KC_A)`, giving a more expected behavior for newer users.
While, this may be fine for most, if you want to specify the whole keycode (eg, `LT(3, KC_A)` from the example above) in the sequence, you can enable this by added `#define LEADER_KEY_STRICT_KEY_PROCESSING` to your `config.h` file. This well then disable the filtering, and you'll need to specify the whole keycode.
While, this may be fine for most, if you want to specify the whole keycode (eg, `LT(3, KC_A)` from the example above) in the sequence, you can enable this by added `#define LEADER_KEY_STRICT_KEY_PROCESSING` to your `config.h` file. This will then disable the filtering, and you'll need to specify the whole keycode.
In addition to the `process_record_user()` function, is the `post_process_record_user()` function. This runs after `process_record` and can be used to do things after a keystroke has been sent. This is useful if you want to have a key pressed before and released after a normal key, for instance.
In this example, we modify most normal keypresses so that `F22` is pressed before the keystroke is normally sent, and release it __only after__ it's been released.
|`rgb_matrix_set_color_all(r, g, b)` |Set all of the LEDs to the given RGB value, where `r`/`g`/`b` are between 0 and 255 (not written to EEPROM) |
|`rgb_matrix_set_color(index, r, g, b)` |Set a single LED to the given RGB value, where `r`/`g`/`b` are between 0 and 255, and `index` is between 0 and `DRIVER_LED_TOTAL` (not written to EEPROM) |
|`rgb_matrix_increase_hue()` |Increase the hue for effect range LEDs. This wraps around at maximum hue |
|`rgb_matrix_decrease_hue()` |Decrease the hue for effect range LEDs. This wraps around at minimum hue |
|`rgb_matrix_increase_sat()` |Increase the saturation for effect range LEDs. This wraps around at maximum saturation |
|`rgb_matrix_decrease_sat()` |Decrease the saturation for effect range LEDs. This wraps around at minimum saturation |
|`rgb_matrix_increase_val()` |Increase the value for effect range LEDs. This wraps around at maximum value |
|`rgb_matrix_decrease_val()` |Decrease the value for effect range LEDs. This wraps around at minimum value |
|`rgb_matrix_sethsv(h, s, v)` |Set LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 |
|`rgb_matrix_sethsv_noeeprom(h, s, v)` |Set LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 (not written to EEPROM) |
### Query Current Status :id=query-current-status
|Function |Description |
|-----------------------|-----------------|
|`rgb_matrix_get_mode()` |Get current mode |
|`rgb_matrix_get_hue()` |Get current hue |
|`rgb_matrix_get_sat()` |Get current sat |
|`rgb_matrix_get_val()` |Get current val |
## Callbacks :id=callbacks
### Indicators :id=indicators
If you want to set custom indicators, such as an LED for Caps Lock, or layer indication, you can use the `rgb_matrix_indicators_kb` or `rgb_matrix_indicators_user` function for that:
```c
voidrgb_matrix_indicators_kb(void){
rgb_matrix_set_color(index,red,green,blue);
}
```
### Suspended state :id=suspended-state
To use the suspend feature, make sure that `#define RGB_DISABLE_WHEN_USB_SUSPENDED true` is added to the `config.h` file.
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.
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.
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:
```c
// Light LEDs 6 to 9 and 12 to 15 red when caps lock is active. Hard to ignore!
Note: For split keyboards with two controllers, both sides need to be flashed when updating the contents of rgblight_layers.
## Functions
If you need to change your RGB lighting in code, for example in a macro to change the color whenever you switch layers, QMK provides a set of functions to assist you. See [`rgblight.h`](https://github.com/qmk/qmk_firmware/blob/master/quantum/rgblight.h) for the full list, but the most commonly used functions include:
@ -90,13 +90,15 @@ Unicode input in QMK works by inputting a sequence of characters to the OS, sort
The following input modes are available:
* **`UC_OSX`**: macOS built-in Unicode hex input. Supports code points up to `0xFFFF` (`0x10FFFF` with Unicode Map).
* **`UC_MAC`**: macOS built-in Unicode hex input. Supports code points up to `0xFFFF` (`0x10FFFF` with Unicode Map).
To enable, go to _System Preferences > Keyboard > Input Sources_, add _Unicode Hex Input_ to the list (it's under _Other_), then activate it from the input dropdown in the Menu Bar.
By default, this mode uses the left Option key (`KC_LALT`) for Unicode input, but this can be changed by defining [`UNICODE_KEY_OSX`](#input-key-configuration) with another keycode.
By default, this mode uses the left Option key (`KC_LALT`) for Unicode input, but this can be changed by defining [`UNICODE_KEY_MAC`](#input-key-configuration) with another keycode.
!> Using the _Unicode Hex Input_ input source may disable some Option based shortcuts, such as Option + Left Arrow and Option + Right Arrow.
!> `UC_OSX` is a deprecated alias of `UC_MAC` that will be removed in a future version of QMK.
* **`UC_LNX`**: Linux built-in IBus Unicode input. Supports code points up to `0x10FFFF` (all possible code points).
Enabled by default and works almost anywhere on IBus-enabled distros. Without IBus, this mode works under GTK apps, but rarely anywhere else.
@ -124,7 +126,7 @@ You can switch the input mode at any time by using one of the following keycodes
@ -180,7 +182,7 @@ You can customize the keys used to trigger Unicode input for macOS, Linux and Wi
You can choose which input modes are available for cycling through. By default, this is disabled. If you want to enable it, limiting it to just the modes you use makes sense. Note that the values in the list are comma-delimited.
You can cycle through the selected modes by using the `UC_MOD`/`UC_RMOD` keycodes, or by calling `cycle_unicode_input_mode(offset)` in your code (`offset` is how many modes to move forward by, so +1 corresponds to `UC_MOD`).
@ -61,10 +61,76 @@ This file is used by the [QMK API](https://github.com/qmk/qmk_api). It contains
All projects need to have a `config.h` file that sets things like the matrix size, product name, USB VID/PID, description and other settings. In general, use this file to set essential information and defaults for your keyboard that will always work.
The `config.h` files can also be placed in sub-folders, and the order in which they are read is as follows:
The `post_config.h` file can be used for additional post-processing, depending on what is specified in the `config.h` file. For example, if you define the `IOS_DEVICE_ENABLE` macro in your keymap-level `config.h` file as follows, you can configure more detailed settings accordingly in the `post_config.h` file:
*`keyboards/top_folder/keymaps/a_keymap/config.h`
```c
#define IOS_DEVICE_ENABLE
```
* `keyboards/top_folder/post_config.h`
```c
#ifndef IOS_DEVICE_ENABLE
// USB_MAX_POWER_CONSUMPTION value for this keyboard
#define USB_MAX_POWER_CONSUMPTION 400
#else
// fix iPhone and iPad power adapter issue
// iOS device need lessthan 100
#define USB_MAX_POWER_CONSUMPTION 100
#endif
#ifdef RGBLIGHT_ENABLE
#ifndef IOS_DEVICE_ENABLE
#define RGBLIGHT_LIMIT_VAL 200
#define RGBLIGHT_VAL_STEP 17
#else
#define RGBLIGHT_LIMIT_VAL 35
#define RGBLIGHT_VAL_STEP 4
#endif
#ifndef RGBLIGHT_HUE_STEP
#define RGBLIGHT_HUE_STEP 10
#endif
#ifndef RGBLIGHT_SAT_STEP
#define RGBLIGHT_SAT_STEP 17
#endif
#endif
```
?> If you define options using `post_config.h` as in the above example, you should not define the same options in the keyboard- or user-level `config.h`.
### `rules.mk`
The presence of this file means that the folder is a keyboard target and can be used in `make` commands. This is where you setup the build environment for your keyboard and configure the default set of features.
The `rules.mk` file can also be placed in a sub-folder, and its reading order is as follows:
Many of the settings written in the `rules.mk` file are interpreted by `common_features.mk`, which sets the necessary source files and compiler options.
?> See `build_keyboard.mk` and `common_features.mk` for more details.
### `<keyboard_name.c>`
This is where you will write custom code for your keyboard. Typically you will write code to initialize and interface with the hardware in your keyboard. If your keyboard consists of only a key matrix with no LEDs, speakers, or other auxiliary hardware this file can be blank.
original document: eae21eed7:docs/arm_debugging.md
git diff eae21eed7 HEAD -- docs/arm_debugging.md | cat
original document: 0.8.58:docs/arm_debugging.md
git diff 0.8.58 HEAD -- docs/arm_debugging.md | cat
-->
このページでは、SWD アダプタとオープンソース/フリーツールを使って ARM MCU をデバッグするためのセットアップ方法について説明します。このガイドでは、GNU MCU Eclipse IDE for C/C++ Developers および OpenOCD を必要な依存関係と一緒にインストールします。
虫アイコンをクリックし、もし全てうまく行けば Debug パースペクティブに移動します。ここでは、main 関数の最初でプログラムカウンタが停止するので、Play ボタンを押します。全てのデバッガのほとんどの機能は ARM MCU で動作しますが、正確な詳細については google があなたのお友達です!
虫アイコンをクリックし、もし全てうまく行けば Debug パースペクティブに移動します。ここでは、main 関数の最初でプログラムカウンタが停止し、Play ボタンが押されるのを待ちます。全てのデバッガのほとんどの機能は Arm MCU で動作しますが、正確な詳細については Google があなたのお友達です!
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.