summaryrefslogtreecommitdiffstats
path: root/docs/custom_quantum_functions.md
diff options
context:
space:
mode:
authorJack Humbert <jack.humb@gmail.com>2017-06-10 20:58:24 +0200
committerJack Humbert <jack.humb@gmail.com>2017-06-10 20:58:24 +0200
commitca01d94005f67ec4fa9528353481faa622d949ae (patch)
treedd6d59d065492e3bb8192263a8a7e7cc0709c48f /docs/custom_quantum_functions.md
parent558db0e03f0f3993e2b7fb5cc3f285393da0a4c3 (diff)
downloadqmk_firmware-ca01d94005f67ec4fa9528353481faa622d949ae.tar.gz
qmk_firmware-ca01d94005f67ec4fa9528353481faa622d949ae.tar.xz
convert docs to lowercase and underscores
Diffstat (limited to 'docs/custom_quantum_functions.md')
-rw-r--r--docs/custom_quantum_functions.md123
1 files changed, 123 insertions, 0 deletions
diff --git a/docs/custom_quantum_functions.md b/docs/custom_quantum_functions.md
new file mode 100644
index 000000000..0fb1c163b
--- /dev/null
+++ b/docs/custom_quantum_functions.md
@@ -0,0 +1,123 @@
+A custom keyboard is about more than sending button presses to your computer. QMK has designed hooks to allow you to inject code, override functionality, and otherwise customize how your keyboard responds in different situations.
+
+## A Word on Keyboards vs Keymap
+
+We have structured QMK as a hierarchy:
+
+* Core (`_quantum`)
+ * Keyboard/Revision (`_kb`)
+ * Keymap (`_user`)
+
+Each of the functions described below can be defined with a `_kb()` suffix or an `_user()` suffix. We intend for you to use the `_kb()` suffix at the Keyboard/Revision level, while the `_user()` suffix should be used at the Keymap level.
+
+When defining functions at the Keyboard/Revision level it is important that your `_kb()` implementation call `_user()` before executing anything else- otherwise the keymap level function will never be called.
+
+## Matrix Initialization Code
+
+* Keyboard/Revision: `void matrix_init_kb(void)`
+* Keymap: `void matrix_init_user(void)`
+
+This function gets called when the matrix is initiated. You should use this function to initialize any custom hardware you may have, such as speakers, LED drivers, or other features which need to be setup after the keyboard powers on.
+
+### Example
+
+```
+void matrix_init_kb(void) {
+ // put your keyboard start-up code here
+ // runs once when the firmware starts up
+ matrix_init_user();
+
+ // JTAG disable for PORT F. write JTD bit twice within four cycles.
+ MCUCR |= (1<<JTD);
+ MCUCR |= (1<<JTD);
+
+ // * Set our LED pins as output
+ DDRB |= (1<<0);
+ DDRB |= (1<<1);
+ DDRB |= (1<<2);
+ DDRB |= (1<<3);
+ DDRB |= (1<<4);
+}
+```
+
+## Matrix Scanning Code
+
+* Keyboard/Revision: `void matrix_scan_kb(void)`
+* Keymap: `void matrix_scan_user(void)`
+
+This function gets called at every matrix scan, which is basically as often as the MCU can handle. Be careful what you put here, as it will get run a lot.
+
+You should use this function if you need custom matrix scanning code. It can also be used for custom status output (such as LED's or a display) or other functionality that you want to trigger regularly even when the user isn't typing.
+
+## Hook Into Key Presses
+
+* Keyboard/Revision: `bool process_record_kb(uint16_t keycode, keyrecord_t *record)`
+* Keymap: `bool process_record_user(uint16_t keycode, keyrecord_t *record)`
+
+This function gets called every time a key is pressed or released. This is particularly useful when defining custom keys or overriding the behavior of existing keys.
+
+The return value is whether or not QMK should continue processing the keycode - returning `false` stops the execution.
+
+The `keycode` variable is whatever is defined in your keymap, eg `MO(1)`, `KC_L`, etc. and can be switch-cased to execute code whenever a particular code is pressed.
+
+The `record` variable contains infomation about the actual press:
+
+```
+keyrecord_t record {
++-keyevent_t event {
+| +-keypos_t key {
+| | +-uint8_t col
+| | +-uint8_t row
+| | }
+| +-bool pressed
+| +-uint16_t time
+| }
+}
+```
+
+The conditional `if (record->event.pressed)` can tell if the key is being pressed or released, and you can execute code based on that.
+
+## LED Control
+
+* Keyboard/Revision: `void led_set_kb(uint8_t usb_led)`
+* Keymap: `void led_set_user(uint8_t usb_led)`
+
+This allows you to control the 5 LED's defined as part of the USB Keyboard spec. It will be called when the state of one of those 5 LEDs changes.
+
+* `USB_LED_NUM_LOCK`
+* `USB_LED_CAPS_LOCK`
+* `USB_LED_SCROLL_LOCK`
+* `USB_LED_COMPOSE`
+* `USB_LED_KANA`
+
+### Example:
+
+```
+void led_set_kb(uint8_t usb_led) {
+ if (usb_led & (1<<USB_LED_NUM_LOCK)) {
+ PORTB |= (1<<0);
+ } else {
+ PORTB &= ~(1<<0);
+ }
+ if (usb_led & (1<<USB_LED_CAPS_LOCK)) {
+ PORTB |= (1<<1);
+ } else {
+ PORTB &= ~(1<<1);
+ }
+ if (usb_led & (1<<USB_LED_SCROLL_LOCK)) {
+ PORTB |= (1<<2);
+ } else {
+ PORTB &= ~(1<<2);
+ }
+ if (usb_led & (1<<USB_LED_COMPOSE_LOCK)) {
+ PORTB |= (1<<3);
+ } else {
+ PORTB &= ~(1<<3);
+ }
+ if (usb_led & (1<<USB_LED_KANA_LOCK)) {
+ PORTB |= (1<<4);
+ } else {
+ PORTB &= ~(1<<4);
+ }
+}
+```