* VIA_ENABLE Tokyo60 PCB
* Update config.h
* Apply suggestions from code review
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* New feature: RGBLIGHT_LAYERS
This feature allows users to define multiple independent layers of lighting
that can be toggled on and off individually, making it easy to use your
RGB lighting to indicate things like active keyboard layer & modifier state.
* Demonstrate built in functions for layer state checking
Also link the video in the docs.
* Follow existing pattern for setting rgblight_status flags
* Eliminate rgblight_is_static_mode since it's not needed
Just check to see if the timer is enabled directly.
* Moved contents of rgblight_reconfig.h to rgblight_post_config.h.
In #3582, rgblight_reconfig.h had to be newly created. Now, the build system of qmk_firmware has a post_cofig feature, so that what was done in rgblight_reconfig.h can now be realized in rgblight_post_config.h.
**This commit does not change the build result.**
Testing script
```shell
# build on master
git checkout master
echo master > /tmp/master_md5.txt
# RGBLIGHT_ENABLE = no
make HELIX=verbose helix/rev2:default:clean
make HELIX=verbose helix/rev2:default
md5 helix_rev2_default.hex >> /tmp/master_md5.txt
# RGBLIGHT_ENABLE = yes, with animations
make HELIX=verbose helix/rev2/back:default:clean
make HELIX=verbose helix/rev2/back:default
md5 helix_rev2_back_default.hex >> /tmp/master_md5.txt
# RGBLIGHT_ENABLE = yes, without animations
make HELIX=verbose,no_ani helix/rev2/back:default:clean
make HELIX=verbose,no_ani helix/rev2/back:default
md5 helix_rev2_back_default.hex >> /tmp/master_md5.txt
# build on refactor_rgblight_reconfig.h
git checkout refactor_rgblight_reconfig.h
echo refactor_rgblight_reconfig.h > /tmp/branch_md5.txt
# RGBLIGHT_ENABLE = no
make HELIX=verbose helix/rev2:default:clean
make HELIX=verbose helix/rev2:default
md5 helix_rev2_default.hex >> /tmp/branch_md5.txt
# RGBLIGHT_ENABLE = yes, with animations
make HELIX=verbose helix/rev2/back:default:clean
make HELIX=verbose helix/rev2/back:default
md5 helix_rev2_back_default.hex >> /tmp/branch_md5.txt
# RGBLIGHT_ENABLE = yes, without animations
make HELIX=verbose,no_ani helix/rev2/back:default:clean
make HELIX=verbose,no_ani helix/rev2/back:default
md5 helix_rev2_back_default.hex >> /tmp/branch_md5.txt
diff -u /tmp/master_md5.txt /tmp/branch_md5.txt
```
Test result:
```
--- /tmp/master_md5.txt 2020-01-03 15:42:22.000000000 +0900
+++ /tmp/branch_md5.txt 2020-01-03 15:42:42.000000000 +0900
@@ -1,4 +1,4 @@
-master
+refactor_rgblight_reconfig.h
MD5 (helix_rev2_default.hex) = f360032edd522448366d471d8f4f8181
MD5 (helix_rev2_back_default.hex) = 0c663acc6cccc44476b3b969ad22a48f
MD5 (helix_rev2_back_default.hex) = e66b1195ff6d38e6e22c975b8ae42fd3
```
* Expressions that are too long are difficult to read, so wrap them.
* Edit the expression again
* remove `defined(RGBLIGHT_ANIMATIONS)` in `tmk_core/common/*/suspend.c`, `tmk_core/protocol/*/main.c`
move contents of rgblight_reconfig.h to rgblight.h.
The following changes were made to rgblight.h.
```diff
+#ifdef RGBLIGHT_USE_TIMER
void rgblight_task(void);
void rgblight_timer_init(void);
void rgblight_timer_enable(void);
void rgblight_timer_disable(void);
void rgblight_timer_toggle(void);
+#else
+#define rgblight_task()
+#define rgblight_timer_init()
+#define rgblight_timer_enable()
+#define rgblight_timer_disable()
+#define rgblight_timer_toggle()
+#endif
```
The following changes were made to tmk_core/common/avr/suspend.c, tmk_core/common/chibios/suspend.c, tmk_core/protocol/chibios/main.c, tmk_core/protocol/lufa/lufa.c, tmk_core/protocol/vusb/main.c.
```diff
-# ifdef RGBLIGHT_ANIMATIONS
rgblight_timer_enable();
-# endif
```
```diff
-#if defined(RGBLIGHT_ANIMATIONS) && defined(RGBLIGHT_ENABLE)
+#if defined(RGBLIGHT_ENABLE)
rgblight_task();
#endif
```
* remove 'defined(RGBLIGHT_ANIMATIONS)' in tmk_core/common/keyboard.c
Co-authored-by: Joel Challis <git@zvecr.com>
* added Palette1202
* removed currently unused cords
* Update keyboards/palette1202/config.h
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Apply suggestions from code review
Co-Authored-By: Drashna Jaelre <drashna@live.com>
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update readme.md
removed unnecessary horizontal line from readme.md
* Update readme.md
Fixed style, make command example
* Removed spaces
* removed unused config.h
* fixed defines
* fixed send string on rotate encoder
* fixed layer numbers for OLED Display
* fixed to use existing function to set default layer
https://github.com/qmk/qmk_firmware/pull/7736#discussion_r366699616
* flipped rotary encoder directions
* Added layer for Clip studio on iOS
* Update keyboards/palette1202/rules.mk
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/palette1202/lib/oled_helper.h
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* is_master, has_usb() move to rev2.[hc]
* Do recent helix/rev2 changes to helix/pico as well.
helix/pico/matrix.c: remove 'is_master'
helix/pico/pico.c: add 'is_master'
helix/pico/pico.h: add 'has_usb()' macro
helix/pico/split_util.c: remove 'setup_handedness()' 'has_usb()', add 'is_helix_master()' etc
* add HELIX=scan option into {rev2/pico}/local_features.mk
Made DEBUG_MATRIX_SCAN_RATE easy to use.
* Changed rules.mk to link "helix/local_drivers/ssd1306.c" only when OLED_ENABLE = yes.
* Added option to use split_common for helix/rev2, helix/pico keyboard.
how to build:
### build helix/pico (HelixPico) with helix current codes
$ make helix/pico:KEY_MAP
$ make helix/pico/back:KEY_MAP
### build helix/rev2 (Helix or Helix beta) with helix current codes
$ make helix:KEY_MAP
$ make helix/rev2/back:KEY_MAP
$ make helix/rev2/under:KEY_MAP
$ make helix/rev2/oled:KEY_MAP
$ make helix/rev2/oled/back:KEY_MAP
$ make helix/rev2/oled/under:KEY_MAP
### build helix/pico (HelixPico) with split_common codes
$ make helix/pico/sc:KEY_MAP
$ make helix/pico/sc/back:KEY_MAP
$ make helix/pico/sc/under:KEY_MAP
### build helix/rev2 (Helix) with split_common codes
$ make helix/rev2/sc:KEY_MAP
$ make helix/rev2/sc/back:KEY_MAP
$ make helix/rev2/sc/under:KEY_MAP
$ make helix/rev2/sc/oled:KEY_MAP
$ make helix/rev2/sc/oledback:KEY_MAP
$ make helix/rev2/sc/oledunder:KEY_MAP
* add matrix_slave_scan_user() to helix/rev2/rev2.c, helix/pico/pico.h
* Changed 'helix:xulkal' to always use split_common and removed ad hoc code.
Added the following line to 'helix/rev2/keymaps/xulkal/rules.mk':
SPLIT_KEYBOARD = yes
Removed the following ad hoc code from 'users/xulkal/custom_oled.c':
#if KEYBOARD_helix_rev2
extern uint8_t is_master;
bool is_keyboard_master(void) { return is_master; }
#endif
* add '#define DIODE_DIRECTION COL2ROW' into helix/{rev2|pico}/config.h
This commit does not change the build result.
* update helix readme
* keyboards/helix/readme.md
* keyboards/helix/pico/keymaps/default/readme.md
* keyboards/helix/rev2/keymaps/default/readme.md
Co-authored-by: mtei <2170248+mtei@users.noreply.github.com>
* rename backlight_soft to match rules.mk
* rename backlight_soft to match rules.mk - update common_features
* Carve out a better location for private driver backlight functionality
* adding Handwired Skeeb Keyboard
* Apply suggestions from fauxpark
* Apply more suggestions from fauxpark and small change to layout
* Apply more suggestions from noroadsleft and last tap dance
* Add buffer based single line pan, arbitrary byte write to buffer
* Change dirty mask to inverse of OLED_BLOCK_TYPE for future proofing larger buffer sizes
* Updating docs to include new functions
* Updating to clarify scroll vs pan
* 15/16 game with lights for the super 16
* Updated readme with style
* adding comments and initial style to keymap
trying to make the code look prettier, need to test by redownloading
* Final style revisions before pull request
* formatting changes, removed config.h
* modified rules.mk, works with changes in PR8314
* formatting
no number of spaces is enough for a newline, whoops
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/1upkeyboards/super16/keymaps/15game/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/1upkeyboards/super16/keymaps/15game/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/1upkeyboards/super16/keymaps/15game/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
Co-authored-by: Sam Reinehr <swreinehr@mines.edu>
Co-authored-by: Ryan <fauxpark@gmail.com>
* add VIA support for neuron
* update neuron vendor and product id
* update neuron product id
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Added more led helpers
* Working keymap
* Added new mouse button an made lower layer toggleable
* Small improvement to process_record_user
* Removed extra layer buttons
* Added Numpad to apply layer
* Moved buttons and added toggle for raise button
* Added Menu,PrintScreen and Windowslock buttons, and left handmouse
* Fixed Scroll Buttons
* Turned TAPPING TOGGLE to 2
* Switched Del and Ctrl on left hand
* Added Home Button to Mouse layer
* Fixed led initialization to avoid red led on boot
* Updated formatting to follow guidelines
* Used enums instead of defines and used layer_state_t type
* Added license
* Moved TAPPING settings to keymap config
* Fixed small formatting issue in keymap.c
* Use GPIO Control instead of lowlevel ports
- minor typo on intro paragraph (the -> them)
- remove note about :check-size target (`make` task now does this automatically)
- heading level for Caterina commands section
- typo regarding Halfkay (come -> comes)
* Add Colemak layout
* Add status bar for mods & locks with a custom font
* Swap DEL and TAB
* Fix media keys and add QMK Configurator layout
* Add dead grave accent on <leader>e
* via configurator can't do AG_TOGG with any key - meh
* same issue - via can't do AG_TOGG
* oops - missed AG_TOGG on the NK65
* add media and mousekeys
* Update keyboards/nk65/keymaps/madhatter/keymap.c
* refactor yd60mq.h
- four-space indent
- use K<row><col> base32hex notation
- rename LAYOUT to LAYOUT_all (with alias for backwards compatibility)
* refactor yd60mq.c to use led_update_kb()
* align rules.mk to AVR template
* refactor default keymap
Also correct positions for KC_NUHS and KC_NUBS.
* update readme
* add Configurator layout support
* initialize the Caps Lock LED pin properly
* Keymap Update
Some key codes have been updated.
naked64:salicylic
7skb:default
* Keymap Update
Some key codes have been updated.
KC_GRAVE to KC_GRV
7skb:default
* Initial commit of majbritt
* Add QMK and VIA support to majbritt
* Change vendor and product id
* Change name
* Change make path
* Move Majbritt into sidderskb directory
* Update keyboards/sidderskb/majbritt/majbritt.c
Co-Authored-By: Drashna Jaelre <drashna@live.com>
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update keyboards/sidderskb/majbritt/keymaps/default/config.h
Co-Authored-By: Ryan <fauxpark@gmail.com>
* remove unused file
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Change include guards to pragma once
* Clean up default keymaps
* Remove some magic numbers and use GPIO macros
* Clean up keyboard.[ch]
* Tidy up info.json and readme
* Align config.h with template
* Split up revision code into subfolders
* rev C-H has no audio, apparently
* Change revc_h to revc and document differences
* Turn off Audio on revb for now, for Travis' sake
* Split info.json into revision folders
* Clean up default keymaps some more
* to ease the maintenance for some boards ibnuda has.
* followed ridingqwerty's suggestion on 8821.
* folloing drashna's suggestion on qmk's 8221.
* following drashn's suggestion on qmk's 8211
* WIP do not merge
* first pass at custom preonic layout
* add auto shift and reset via leader key
* Update readme
* update copyright notice
* formatting changes
* fix: use MO instead of process_record_user
* added backslash and moved grave position
* remove extraneous 'j' characer in NUMPAD template
* update template formatting
* remove process_record_user
* swap "!" with "@"
* fix readme formatting
* update readme layout image
* restore settings layer
* add windows minimize sequence
* fix: switch to correct seq function for three-key sequence
* fix: missing semicolon
* refactor: move keymap to userspace and generic 5x12 layout
* add numlock to numpad layer
* add readme
* update readme formatting
* remove unused wrappers from layout keymap
* update readme title to reflect new location
* remove alfrdmalr directory from preonic/keymaps
* add ortho 4x12 support
* add 'trilayer' settings and update keymap
* update SYMBOLS layer to SYMBOL
* remove minimize sequence
* clean up user config
* add brightness controls
* update settings ascii
* moved some symbols around to make vim/linux smoother
* Reduce PROGMEM usage for keycode map
Bit-pack the keycode bool array to gain back a small amount of flash space.
The trade-off is an increase in runtime instructions when running macros.
It does make the code a bit harder to read, as well as maintain.
For configs that use send_string() et al, it saves ~100 bytes.
* Switch to macro and common definition
Rewrite the array declarations so both the unpacked (original) and
packed LUT arrays can use the same value definitions. This is done by
defining a macro that "knows what to do".
This makes the code much easier to read and maintain.
* Fix macro typos and improve perf
Pack the bits in a more efficient order for extraction.
And also fix the copy/paste error in the macro...
* Switch fully to packed LUT
Some minor reformatting.
Compile tested all sendstring_xyz.h to make sure they were converted
properly. Also checked that an unconverted version would generate a
compile error.
* Apply whitespace suggestions from code review
Co-Authored-By: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* [Docs] Update ISP Flashing guide
* Apply suggestions from code review
AKA why you shouldn't write docs at 2am
Co-Authored-By: fauxpark <fauxpark@gmail.com>
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update workding for planck-qmk-dfu
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Keyboard: revamp frosty-flake leds
This commit transitions bpiphany/frosty_flake to led_update_{kb,user}
and rewrites the AVR bit twiddling logic to use the standard QMK GPIO
API.
* Keyboard: rewrite frosty_flake's matrix reader to be a lite custom matrix
This commit replaces frosty_flake's custom matrix and debounce logic
with a "lite" custom matrix. In addition to being somewhat clearer, this
allows a consumer of the flake board to choose their own debouncing
algorithm. The one closest to the implementation originally in use is
sym_g, but this opens us up to supporting eager_pk and eager_pr.
The original matrix code was 18 columns for 8 rows, but using a single
row read and unpacking the bits into individual columns. To simplify,
I've changed the key layout to be 8C 18R instead of 18C 8R: this lets us
use a single read directly into the matrix _and_ drop down to a uint8_t
instead of a uint32_t for matrix_row_t.
Since we're no longer implementing our own debouncing and row unpacking,
we save ~400 bytes on the final firmware image.
Fully tested against a CM Storm QFR hosting the flake -- this commit
message was written using the new matrix code.
Firmware Sizes (assuming stock configuration as of 42d6270f2)
Matrix+Debounce Size (bytes)
--------------- ------------
original 17740
new + sym_g 17284
new + eager_pr 18106
new + eager_pk 18204
I expect that there are some scanning speed benefits as well.
* Keyboard: update frosty_flake's UNUSED_PINS
* Keyboard: Remove meaningless weak redefinitions from frosty
These are not necessary (and all of them already live somewhere in
Quantum).
QMK (*Quantum Mechanical Keyboard*) is an open source community that maintains QMK Firmware, QMK Toolbox, qmk.fm, and these docs. QMK Firmware is a keyboard firmware based on the [tmk\_keyboard](http://github.com/tmk/tmk_keyboard) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.com), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/). It has also been ported to ARM chips using ChibiOS. You can use it to power your own hand-wired or custom keyboard PCB.
QMK (*Quantum Mechanical Keyboard*) is an open source community centered around developing computer input devices. The community encompasses all sorts of input devices, such as keyboards, mice, and MIDI devices. A core group of collaborators maintains [QMK Firmware](https://github.com/qmk/qmk_firmware), [QMK Configurator](https://config.qmk.fm), [QMK Toolbox](https://github.com/qmk/qmk_toolbox), [qmk.fm](https://qmk.fm), and this documentation with the help of community members like you.
## How to Get It
## Get Started
If you plan on contributing a keymap, keyboard, or features to QMK, the easiest thing to do is [fork the repo through Github](https://github.com/qmk/qmk_firmware#fork-destination-box), and clone your repo locally to make your changes, push them, then open a [Pull Request](https://github.com/qmk/qmk_firmware/pulls) from your fork.
Totally new to QMK? There are two ways to get started:
Otherwise, you can clone it directly with `git clone https://github.com/qmk/qmk_firmware`. Do not download the zip or tar files; a git repository is required to download the submodules in order to compile.
* Just select your keyboard from the dropdown and program your keyboard.
* We have an [introductory video](https://www.youtube.com/watch?v=-imgglzDMdY) you can watch.
* There is also an overview [document you can read](newbs_building_firmware_configurator.md).
* Advanced: [Use The Source](newbs.md)
* More powerful, but harder to use
## How to Compile
## Make It Yours
Before you are able to compile, you'll need to [install an environment](getting_started_build_tools.md) for AVR or/and ARM development. Once that is complete, you'll use the `make` command to build a keyboard and keymap with the following notation:
QMK has lots of [features](features.md) to explore, and a good deal of reference documentation to dig through. Most features are taken advantage of by modifying your [keymap](keymap.md), and changing the [keycodes](keycodes.md).
make planck/rev4:default
## Need help?
This would build the `rev4` revision of the `planck` with the `default` keymap. Not all keyboards have revisions (also called subprojects or folders), in which case, it can be omitted:
Check out the [support page](support.md) to see how you can get help using QMK.
make preonic:default
## Give Back
## How to Customize
There are a lot of ways you can contribute to the QMK Community. The easiest way to get started is to use it and spread the word to your friends.
QMK has lots of [features](features.md) to explore, and a good deal of [reference documentation](http://docs.qmk.fm) to dig through. Most features are taken advantage of by modifying your [keymap](keymap.md), and changing the [keycodes](keycodes.md).
* Help people out on our forums and chat rooms:
* [/r/olkb](https://www.reddit.com/r/olkb/)
* [Discord Server](https://discord.gg/Uq7gcHh)
* Contribute to our documentation by clicking "Edit This Page" at the bottom
* [Translate our documentation into your language](translating.md)
* [Report a bug](https://github.com/qmk/qmk_firmware/issues/new/choose)
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 is currently AVR-only. The values returned are 10-bit integers (0-1023) mapped between 0V and VCC (usually 5V or 3.3V).
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).
## Usage
@ -20,6 +20,8 @@ Then place this include at the top of your code:
@ -39,8 +41,84 @@ Then place this include at the top of your code:
<sup>\* The ATmega328P possesses two extra ADC channels; however, they are not present on the DIP pinout, and are not shared with GPIO pins. You can use `adc_read()` directly to gain access to these.</sup>
### ARM
Note that some of these pins are doubled-up on ADCs with the same channel. This is because the pins can be used for either ADC.
Also note that the F0 and F3 use different numbering schemes. The F0 has a single ADC and the channels are 0-based, whereas the F3 has 4 ADCs and the channels are 1 based. This is because the F0 uses the `ADCv1` implementation of the ADC, whereas the F3 uses the `ADCv3` implementation.
|`analogReference(mode)` |Sets the analog voltage reference source. Must be one of `ADC_REF_EXTERNAL`, `ADC_REF_POWER` or `ADC_REF_INTERNAL`.|
@ -48,3 +126,28 @@ Then place this include at the top of your code:
|`analogReadPin(pin)` |Reads the value from the specified QMK pin, eg. `F6` for ADC6 on the ATmega32U4. |
|`pinToMux(pin)` |Translates a given QMK pin to a mux value. If an unsupported pin is given, returns the mux value for "0V (GND)". |
|`adc_read(mux)` |Reads the value from the ADC according to the specified mux. See your MCU's datasheet for more information. |
### ARM
Note that care was taken to match all of the functions used for AVR devices, however complications in the ARM platform prevent that from always being possible. For example, the `STM32` chips do not have assigned Arduino pins. We could use the default pin numbers, but those numbers change based on the package type of the device. For this reason, please specify your target pins with their identifiers (`A0`, `F3`, etc.). Also note that there are some variants of functions that accept the target ADC for the pin. Some pins can be used for multiple ADCs, and this specified can help you pick which ADC will be used to interact with that pin.
|`analogReadPin(pin)` |Reads the value from the specified QMK pin, eg. `A0` for channel 0 on the STM32F0 and ADC1 channel 1 on the STM32F3. Note that if a pin can be used for multiple ADCs, it will pick the lower numbered ADC for this function. eg. `C0` will be channel 6 of ADC 1 when it could be used for ADC 2 as well.|
|`analogReadPinAdc(pin, adc)`|Reads the value from the specified QMK pin and ADC, eg. `C0, 1` will read from channel 6, ADC 2 instead of ADC 1. Note that the ADCs are 0-indexed for this function.|
|`pinToMux(pin)` |Translates a given QMK pin to a channel and ADC combination. If an unsupported pin is given, returns the mux value for "0V (GND)".|
|`adc_read(mux)` |Reads the value from the ADC according to the specified pin and adc combination. See your MCU's datasheet for more information.|
## Configuration
## ARM
The ARM implementation of the ADC has a few additional options that you can override in your own keyboards and keymaps to change how it operates.
|ADC_CIRCULAR_BUFFER|`bool`|`false` |If `TRUE`, then the implementation will use a circular buffer.|
|ADC_NUM_CHANNELS |`int` |`1` |Sets the number of channels that will be scanned as part of an ADC operation. The current implementation only supports `1`.|
|ADC_BUFFER_DEPTH |`int` |`2` |Sets the depth of each result. Since we are only getting a 12-bit result by default, we set this to `2` bytes so we can contain our one value. This could be set to 1 if you opt for a 8-bit or lower result.|
|ADC_SAMPLING_RATE |`int` |`ADC_SMPR_SMP_1P5` |Sets the sampling rate of the ADC. By default, it is set to the fastest setting. Please consult the corresponding `hal_adc_lld.h` in ChibiOS for your specific microcontroller for further documentation on your available options.|
|ADC_RESOLUTION |`int` |`ADC_CFGR1_RES_12BIT`|The resolution of your result. We choose 12 bit by default, but you can opt for 12, 10, 8, or 6 bit. Please consult the corresponding `hal_adc_lld.h` in ChibiOS for your specific microcontroller for further documentation on your available options.|
This page attempts to introduce developers to the QMK Compiler. It does not go into nitty gritty details- for that you should read code. What this will give you is a framework to hang your understanding on as you read the code.
# Overview
The QMK Compile API consists of a few movings parts:
API Clients interact exclusively with the API service. This is where they submit jobs, check status, and download results. The API service inserts compile jobs into [Redis Queue](https://python-rq.org) and checks both RQ and S3 for the results of those jobs.
Workers fetch new compile jobs from RQ, compile them, and then upload the source and the binary to an S3 compatible storage engine.
# Workers
QMK Compiler Workers are responsible for doing the actual building. When a worker pulls a job from RQ it does several things to complete that job:
* Make a fresh qmk_firmware checkout
* Use the supplied layers and keyboard metadata to build a `keymap.c`
* Build the firmware
* Zip a copy of the source
* Upload the firmware, source zip, and a metadata file to S3.
* Report the status of the job to RQ
# API Service
The API service is a relatively simple Flask application. There are a few main views you should understand.
## @app.route('/v1/compile', methods=['POST'])
This is the main entrypoint for the API. A client's interaction starts here. The client POST's a JSON document describing their keyboard, and the API does some (very) basic validation of that JSON before submitting the compile job.
This is the most frequently called endpoint. It pulls the job details from redis, if they're still available, or the cached job details on S3 if they're not.
This page describes using the QMK API. If you are an application developer you can use this API to compile firmware for any [QMK](https://qmk.fm) Keyboard.
## Overview
This service is an asynchronous API for compiling custom keymaps. You POST some JSON to the API, periodically check the status, and when your firmware has finished compiling you can download the resulting firmware and (if desired) source code for that firmware.
As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's `LAYOUT` macro. If a keyboard supports mulitple `LAYOUT` macros you can specify which macro to use.
## Submitting a Compile Job
To compile your keymap into a firmware simply POST your JSON to the `/v1/compile` endpoint. In the following example we've placed the JSON payload into a file named `json_data`.
```
$ curl -H "Content-Type: application/json" -X POST -d "$(<json_data)"http://api.qmk.fm/v1/compile
{
"enqueued": true,
"job_id": "ea1514b3-bdfc-4a7b-9b5c-08752684f7f6"
}
```
## Checking The Status
After submitting your keymap you can check the status using a simple HTTP GET call:
The QMK API provides an asynchronous API that Web and GUI tools can use to compile arbitrary keymaps for any keyboard supported by [QMK](http://qmk.fm/). The stock keymap template supports all QMK keycodes that do not require supporting C code. Keyboard maintainers can supply their own custom templates to enable more functionality.
## App Developers
If you are an app developer interested in using this API in your application you should head over to [Using The API](api_docs.md).
## Keyboard Maintainers
If you would like to enhance your keyboard's support in the QMK Compiler API head over to the [Keyboard Support](reference_configurator_support.md) section.
## Backend Developers
If you are interested in working on the API itself you should start by setting up a [Development Environment](api_development_environment.md), then check out [Hacking On The API](api_development_overview.md).
A QMK collaborator is a keyboard maker or designer that is interested in helping QMK grow and fully support their keyboard(s), and encouraging their users and customers to submit features, ideas, and keymaps. We're always looking to add more keyboards and collaborators, but we ask that they fulfill these requirements:
* **Have a PCB available for sale.** Unfortunately there's just too much variation and complications with handwired keyboards.
* **Maintain your keyboard in QMK.** This may just require an initial setup to get your keyboard working, but it could also include accommodating changes made to QMK's core that might break or render any custom code redundant.
* **Approve and merge keymap pull requests for your keyboard.** We like to encourage users to contribute their keymaps for others to see and work from when creating their own.
If you feel you meet these requirements, shoot us an email at hello@qmk.fm with an introduction and some links to your keyboard!
This command is similar to `qmk compile`, but can also target a bootloader. The bootloader is optional, and is set to `:flash` by default.
To specify a different bootloader, use `-bl <bootloader>`. Visit <https://docs.qmk.fm/#/flashing>
for more details of the available bootloaders.
To specify a different bootloader, use `-bl <bootloader>`. Visit the [Flashing Firmware](flashing.md) guide for more details of the available bootloaders.
**Usage for Configurator Exports**:
@ -232,14 +231,14 @@ Check your environment and report problems only:
qmk doctor -n
## `qmk json-keymap`
## `qmk json2c`
Creates a keymap.c from a QMK Configurator export.
@ -4,7 +4,7 @@ This document explains how `qmk config` works.
# Introduction
Configuration for QMK CLI is a key/value system. Each key consists of a subcommand and an argument name separated by a period. This allows for a straightforward and direct translation between config keys and the arguments they set.
Configuration for the QMK CLI is a key/value system. Each key consists of a subcommand and an argument name separated by a period. This allows for a straightforward and direct translation between config keys and the arguments they set.
@ -136,22 +136,22 @@ If you define these options you will enable the associated feature, which may in
* enables handling for per key `TAPPING_TERM` settings
* `#define RETRO_TAPPING`
* tap anyway, even after TAPPING_TERM, if there was no other key interruption between press and release
* See [Retro Tapping](feature_advanced_keycodes.md#retro-tapping) for details
* See [Retro Tapping](tap_hold.md#retro-tapping) for details
* `#define TAPPING_TOGGLE 2`
* how many taps before triggering the toggle
* `#define PERMISSIVE_HOLD`
* makes tap and hold keys trigger the hold if another key is pressed before releasing, even if it hasn't hit the `TAPPING_TERM`
* See [Permissive Hold](feature_advanced_keycodes.md#permissive-hold) for details
* See [Permissive Hold](tap_hold.md#permissive-hold) for details
* `#define PERMISSIVE_HOLD_PER_KEY`
* enabled handling for per key `PERMISSIVE_HOLD` settings
* `#define IGNORE_MOD_TAP_INTERRUPT`
* makes it possible to do rolling combos (zx) with keys that convert to other keys on hold, by enforcing the `TAPPING_TERM` for both keys.
* See [Mod tap interrupt](feature_advanced_keycodes.md#ignore-mod-tap-interrupt) for details
* See [Ignore Mod Tap Interrupt](tap_hold.md#ignore-mod-tap-interrupt) for details
* `#define IGNORE_MOD_TAP_INTERRUPT_PER_KEY`
* enables handling for per key `IGNORE_MOD_TAP_INTERRUPT` settings
* `#define TAPPING_FORCE_HOLD`
* makes it possible to use a dual role key as modifier shortly after having been tapped
* See [Hold after tap](feature_advanced_keycodes.md#tapping-force-hold)
* See [Tapping Force Hold](tap_hold.md#tapping-force-hold)
* Breaks any Tap Toggle functionality (`TT` or the One Shot Tap Toggle)
* `#define TAPPING_FORCE_HOLD_PER_KEY`
* enables handling for per key `TAPPING_FORCE_HOLD` settings
@ -190,6 +190,8 @@ If you define these options you will enable the associated feature, which may in
* pin the DI on the WS2812 is hooked-up to
* `#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.
* `#define RGBLED_NUM 12`
* number of LEDs
* `#define RGBLIGHT_SPLIT`
@ -335,7 +337,7 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i
* `bootloadHID`
* `USBasp`
## Feature Options
## Feature Options :id=feature-options
Use these to enable or disable building certain features. The more you have enabled the bigger your firmware will be, and you run the risk of building a firmware too large for your MCU.
This page describes the steps for building your firmware in QMK Configurator.
## Step 1: Select Your Keyboard
Click the drop down box and select the keyboard you want to create a keymap for.
?> If your keyboard has several versions, make sure you select the correct one.
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? -->
## Step 2: Select Your Keyboard Layout
Choose the layout that best represents the keymap you want to create. Some keyboards do not have enough layouts or correct layouts defined yet. They will be supported in the future.
!> Sometimes there isn't a layout that supports your exact build. In that case select `LAYOUT_all`.
## Step 3: Name Your Keymap
Call this keymap what you want.
?> If you are running into issues when compiling, it may be worth changing this name, as it may already exist in the QMK Firmware repo.
## Step 4: Define Your Keymap
Keycode Entry is accomplished in one of 3 ways:
1. Drag and drop
2. Clicking on an empty spot on the layout, then clicking the keycode you desire
3. Clicking on an empty spot on the layout, then pressing the physical key on your keyboard
?> Hover your mouse over a key and a short blurb will tell you what that keycode does. For a more verbose description please see:
!> If your selected layout doesn't match your physical build leave the unused keys blank. If you're not sure which key is in use, for example you have a one backspace key but `LAYOUT_all` has 2 keys, put the same keycode in both locations.
## Step 5: Save Your Keymap for Future Changes
When you're satisfied with your keymap or just want to work on it later, press the `Export Keymap` button. It will save your keymap to your computer. You can then load this .json file in the future by pressing the `Import Keymap` button.
!> **CAUTION:** This is not the same type of .json file used for kbfirmware.com or any other tool. If you try to use this for those tools, or the .json from those tools with QMK Configurator, you will encounter problems.
## Step 6: Compile Your Firmware File
Press the green `Compile` button.
When the compilation is done, you will be able to press the green `Download Firmware` button.
## Next steps: Flashing Your Keyboard
Please refer to [Flashing Firmware](newbs_flashing.md).
If the .json file was generated with QMK Configurator, congratulations you have stumbled upon a bug. File an issue at [qmk_configurator](https://github.com/qmk/qmk_configurator/issues).
If not... how did you miss the big bold message at the top saying not to use other .json files?
## There are extra spaces in my layout? What do I do?
If you're referring to having three spots for space bar, the best course of action is to just fill them all with Space. The same can be done for Backspace and Shift keys.
### Previewing the Documentation :id=previewing-the-documentation
Before opening a pull request, you can preview your changes if you have set up the development environment by running this command from the `qmk_firmware/` folder:
@ -4,7 +4,7 @@ For a lot of people a custom keyboard is about more than sending button presses
This page does not assume any special knowledge about QMK, but reading [Understanding QMK](understanding_qmk.md) will help you understand what is going on at a more fundamental level.
## A Word on Core vs Keyboards vs Keymap
## A Word on Core vs Keyboards vs Keymap :id=a-word-on-core-vs-keyboards-vs-keymap
We have structured QMK as a hierarchy:
@ -34,7 +34,7 @@ enum my_keycodes {
};
```
## Programming the Behavior of Any Keycode
## Programming the Behavior of Any Keycode :id=programming-the-behavior-of-any-keycode
When you want to override the behavior of an existing key, or define the behavior for a new key, you should use the `process_record_kb()` and `process_record_user()` functions. These are called by QMK during key processing before the actual key event is handled. If these functions return `true` QMK will process the keycodes as usual. That can be handy for extending the functionality of a key rather than replacing it. If these functions return `false` QMK will skip the normal key handling, and it will be up to you to send any key up or down events that are required.
Most keymaps have an image depicting the layout. You can use [Keyboard Layout Editor](http://keyboard-layout-editor.com) to create an image. Upload it to [Imgur](http://imgur.com) or another hosting service, please do not include images in your Pull Request.
Un colaborador QMK es un maker o diseñador de teclados que tiene interés en ayudar a QMK a crecer y mantener sus teclado(s), y alentar a los usuarios y clientes a presentar herramientas, ideas, y keymaps. Siempre procuramos agregar más teclados y colaboradores, pero pedimos que cumplan los siguientes requisitos:
* **Tener un PCB disponible a la venta.** Desafortunadamente, hay demasiada variación y complicaciones con teclados cableados a mano.
* **Realizar el mantenimiento de tu teclado en QMK.** Este podría requirir un setup inicial para hacer que tu teclado funcione, pero también podría incluir adaptarse a cambios hecho al base de QMK que podrían descomponer o rendir código superfluo.
* **Aprobar e incorporar pull requests de keymaps para tu teclado.** Nos gusta alentar a los usuarios a contribuir sus keymaps para que otros los vean y los puedan usar para crear sus propios.
Si sientes que cumples los requisitos, ¡mándanos un email a hello@qmk.fm con una introducción y algunos enlaces para tu teclado!
[QMK](https://github.com/qmk), short for Quantum Mechanical Keyboard, is a group of people building tools for custom keyboards. We started with the [QMK firmware](https://github.com/qmk/qmk_firmware), a heavily modified fork of [TMK](https://github.com/tmk/tmk_keyboard).
## I don't know where to start!
If this is the case, then you should start with our [Newbs Guide](newbs.md). There is a lot of great info there, and that should cover everything you need to get started.
If that's an issue, hop onto the [QMK Configurator](https://config.qmk.fm), as that will handle a majority of what you need there.
## How can I flash the firmware I built?
First, head to the [Compiling/Flashing FAQ Page](faq_build.md). There is a good deal of info there, and you'll find a bunch of solutions to common issues there.
## What if I have an issue that isn't covered here?
Okay, that's fine. Then please check the [open issues in our GitHub](https://github.com/qmk/qmk_firmware/issues) to see if somebody is experiencing the same thing (make sure it's not just similar, but actually the same).
If you can't find anything, then please open a [new issue](https://github.com/qmk/qmk_firmware/issues/new)!
## What if I found a bug?
Then please open an [issue](https://github.com/qmk/qmk_firmware/issues/new), and if you know how to fix it, open up a Pull Request on GitHub with the fix.
## But `git` and `GitHub` are intimidating!
Don't worry, we have some pretty nice [Guidelines](newbs_git_best_practices.md) on how to start using `git` and GitHub to make things easier to develop.
Additionally, you can find additional `git` and GitHub related links [here](newbs_learn_more_resources.md).
## I have a Keyboard that I want to add support for
Awesome! Open up a Pull Request for it. We'll review the code, and merge it!
### What if I want to do brand it with `QMK`?
That's amazing! We would love to assist you with that!
In fact, we have a [whole page](https://qmk.fm/powered/) dedicated to adding QMK Branding to your page and keyboard. This covers pretty much everything you need (knowledge and images) to officially support QMK.
If you have any questions about this, open an issue or head to [Discord](https://discord.gg/Uq7gcHh).
## What Differences Are There Between QMK and TMK?
TMK was originally designed and implemented by [Jun Wako](https://github.com/tmk). QMK started as [Jack Humbert](https://github.com/jackhumbert)'s fork of TMK for the Planck. After a while Jack's fork had diverged quite a bit from TMK, and in 2015 Jack decided to rename his fork to QMK.
## How Can I Make Custom Names For Complex Keycodes?
Sometimes, for readability's sake, it's useful to define custom names for some keycodes. People often define custom names using `#define`. For example:
```c
#define FN_CAPS LT(_FL, KC_CAPSLOCK)
#define ALT_TAB LALT(KC_TAB)
```
This will allow you to use `FN_CAPS` and `ALT_TAB` in your keymap, keeping it more readable.
## Some Of My Keys Are Swapped Or Not Working
QMK has two features, Bootmagic and Command, which allow you to change the behavior of your keyboard on the fly. This includes, but is not limited to, swapping Ctrl/Caps, disabling Gui, swapping Alt/Gui, swapping Backspace/Backslash, disabling all keys, and other behavioral modifications.
@ -192,7 +192,7 @@ To change the behavior of the backlighting, `#define` these in your `config.h`:
|`BACKLIGHT_PWM_CHANNEL` |`3` |The PWM channel to use, see ST datasheets for pin to PWM channel mapping. Unless you are designing your own keyboard, you shouldn't need to change this|
|`BACKLIGHT_PAL_MODE` |`2` |The pin alternative function to use, see ST datasheets for pin AF mapping. Unless you are designing your own keyboard, you shouldn't need to change this|
## Software PWM Driver
## Software PWM Driver :id=software-pwm-driver
Emulation of PWM while running other keyboard tasks, it offers maximum hardware compatibility without extra platform configuration. The tradeoff is the backlight might jitter when the keyboard is busy. To enable, add this to your rules.mk:
@ -121,7 +121,7 @@ If you would like to change the hotkey assignments for Bootmagic, `#define` thes
|`BOOTMAGIC_KEY_DEFAULT_LAYER_6` |`KC_6` |Make layer 6 the default layer |
|`BOOTMAGIC_KEY_DEFAULT_LAYER_7` |`KC_7` |Make layer 7 the default layer |
# Bootmagic Lite
# 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.
@ -16,7 +16,7 @@ First, enable Key Lock by setting `KEY_LOCK_ENABLE = yes` in your `rules.mk`. Th
## Caveats
Key Lock is only able to hold standard action keys and [One Shot modifier](feature_advanced_keycodes.md#one-shot-keys) keys (for example, if you have your Shift defined as `OSM(KC_LSFT)`).
Key Lock is only able to hold standard action keys and [One Shot modifier](one_shot_keys.md) keys (for example, if you have your Shift defined as `OSM(KC_LSFT)`).
This does not include any of the QMK special functions (except One Shot modifiers), or shifted versions of keys such as `KC_LPRN`. If it's in the [Basic Keycodes](keycodes_basic.md) list, it can be held.
By default, the Leader Key feature will filter the keycode out of [`Mod-Tap`](feature_advanced_keycodes.md#mod-tap) 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_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.
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.
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.