summaryrefslogtreecommitdiffstats
path: root/Custom-Quantum-Functions.md
diff options
context:
space:
mode:
authorskullydazed <skullydazed@users.noreply.github.com>2017-04-04 22:33:12 -0700
committerskullydazed <skullydazed@users.noreply.github.com>2017-04-04 22:33:12 -0700
commit34836a16ed44b8e70738178602e0475f665242a8 (patch)
treede60325190c2934b6004625eb27256fdf9f7332e /Custom-Quantum-Functions.md
parentb65282f69f8a46c3543b3e83b0f275534501d8f8 (diff)
Updated Custom Quantum Functions (markdown)
Diffstat (limited to 'Custom-Quantum-Functions.md')
-rw-r--r--Custom-Quantum-Functions.md16
1 files changed, 12 insertions, 4 deletions
diff --git a/Custom-Quantum-Functions.md b/Custom-Quantum-Functions.md
index bdacd31d3c..c4bf418e8a 100644
--- a/Custom-Quantum-Functions.md
+++ b/Custom-Quantum-Functions.md
@@ -49,9 +49,14 @@ This function gets called at every matrix scan, which is basically as often as t
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.
-## `bool process_record_kb(uint16_t keycode, keyrecord_t *record)` and `bool process_record_user(uint16_t keycode, keyrecord_t *record)`
+## Hook Into Key Presses
-This function gets called every time a key is pressed or released. This is where you should define most custom functionality. The return value is whether or not QMK should continue processing the keycode - returning `false` stops the execution.
+* 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.
@@ -72,7 +77,10 @@ keyrecord_t record {
The conditional `if (record->event.pressed)` can tell if the key is being pressed or released, and you can execute code based on that.
-## `void led_set_kb(uint8_t usb_led)` and `void led_set_user(uint8_t usb_led)`
+## 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.
@@ -82,7 +90,7 @@ This allows you to control the 5 LED's defined as part of the USB Keyboard spec.
* `USB_LED_COMPOSE`
* `USB_LED_KANA`
-This is a typical pattern for lighting LED's to match the `USB_LED_*` state
+#### Example:
```
void led_set_kb(uint8_t usb_led) {