diff options
author | Jack Humbert <jack.humb@gmail.com> | 2017-06-10 12:26:09 -0400 |
---|---|---|
committer | GitHub <noreply@github.com> | 2017-06-10 12:26:09 -0400 |
commit | 163754f363b4dd27f5433b251a9cce918106f02f (patch) | |
tree | d50bd374e3c7b287381ffca1d6a14af9201d61fc /docs | |
parent | ad49086be54f4299b16cb306ca21571a0bb81e3c (diff) | |
download | qmk_firmware-163754f363b4dd27f5433b251a9cce918106f02f.tar.gz qmk_firmware-163754f363b4dd27f5433b251a9cce918106f02f.zip |
Create Home.md
Diffstat (limited to 'docs')
-rw-r--r-- | docs/Home.md | 49 |
1 files changed, 0 insertions, 49 deletions
diff --git a/docs/Home.md b/docs/Home.md index bc1d25bf2..500712a22 100644 --- a/docs/Home.md +++ b/docs/Home.md | |||
@@ -132,52 +132,3 @@ case MACRO_RAISED: | |||
132 | 132 | ||
133 | Enable the backlight from the Makefile. | 133 | Enable the backlight from the Makefile. |
134 | 134 | ||
135 | # Custom Quantum functions | ||
136 | |||
137 | All of these functions are available in the `*_kb()` or `*_user()` variety. `kb` ones should only be used in the `<keyboard>/<keyboard>.c` file, and `user` ones should only be used in the `keymap.c`. The keyboard ones call the user ones - it's necessary to keep these calls to allow the keymap functions to work correctly. | ||
138 | |||
139 | ## `void matrix_init_*(void)` | ||
140 | |||
141 | This function gets called when the matrix is initiated, and can contain start-up code for your keyboard/keymap. | ||
142 | |||
143 | ## `void matrix_scan_*(void)` | ||
144 | |||
145 | 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. | ||
146 | |||
147 | ## `bool process_record_*(uint16_t keycode, keyrecord_t *record)` | ||
148 | |||
149 | This function gets called on every keypress/release, and is where you can define custom functionality. The return value is whether or not QMK should continue processing the keycode - returning `false` stops the execution. | ||
150 | |||
151 | 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. | ||
152 | |||
153 | The `record` variable contains infomation about the actual press: | ||
154 | |||
155 | ``` | ||
156 | keyrecord_t record { | ||
157 | keyevent_t event { | ||
158 | keypos_t key { | ||
159 | uint8_t col | ||
160 | uint8_t row | ||
161 | } | ||
162 | bool pressed | ||
163 | uint16_t time | ||
164 | } | ||
165 | } | ||
166 | ``` | ||
167 | |||
168 | The conditional `if (record->event.pressed)` can tell if the key is being pressed or released, and you can execute code based on that. | ||
169 | |||
170 | ## `void led_set_*(uint8_t usb_led)` | ||
171 | |||
172 | This gets called whenever there is a state change on your host LEDs \(eg caps lock, scroll lock, etc\). The LEDs are defined as: | ||
173 | |||
174 | ``` | ||
175 | #define USB_LED_NUM_LOCK 0 | ||
176 | #define USB_LED_CAPS_LOCK 1 | ||
177 | #define USB_LED_SCROLL_LOCK 2 | ||
178 | #define USB_LED_COMPOSE 3 | ||
179 | #define USB_LED_KANA 4 | ||
180 | ``` | ||
181 | |||
182 | and can be tested against the `usb_led` with a conditional like `if (usb_led & (1<<USB_LED_CAPS_LOCK))` - if this is true, you can turn your LED on, otherwise turn it off. | ||
183 | |||