diff options
Diffstat (limited to 'docs')
30 files changed, 254 insertions, 361 deletions
diff --git a/docs/_summary.md b/docs/_summary.md index 01808bd675..ce579cb071 100644 --- a/docs/_summary.md +++ b/docs/_summary.md @@ -41,7 +41,6 @@ * [Keymap Overview](keymap.md) * Development Environments * [Docker Guide](getting_started_docker.md) - * [Vagrant Guide](getting_started_vagrant.md) * Flashing * [Flashing](flashing.md) * [Flashing ATmega32A (ps2avrgb)](flashing_bootloadhid.md) diff --git a/docs/config_options.md b/docs/config_options.md index 5bfb7c5d58..5ea71d993e 100644 --- a/docs/config_options.md +++ b/docs/config_options.md @@ -150,7 +150,7 @@ If you define these options you will enable the associated feature, which may in * `#define TAPPING_TERM_PER_KEY` * 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 + * tap anyway, even after `TAPPING_TERM`, if there was no other key interruption between press and release * See [Retro Tapping](tap_hold.md#retro-tapping) for details * `#define RETRO_TAPPING_PER_KEY` * enables handling for per key `RETRO_TAPPING` settings @@ -161,9 +161,6 @@ If you define these options you will enable the associated feature, which may in * 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 [Ignore Mod Tap Interrupt](tap_hold.md#ignore-mod-tap-interrupt) for details * `#define QUICK_TAP_TERM 100` * tap-then-hold timing to use a dual role key to repeat keycode * See [Quick Tap Term](tap_hold.md#quick-tap-term) @@ -217,7 +214,7 @@ If you define these options you will enable the associated feature, which may in ## RGB Light Configuration -* `#define RGB_DI_PIN D7` +* `#define WS2812_DI_PIN D7` * pin the DI on the WS2812 is hooked-up to * `#define RGBLIGHT_LAYERS` * Lets you define [lighting layers](feature_rgblight.md?id=lighting-layers) that can be toggled on or off. Great for showing the current keyboard layer or caps lock state. @@ -233,7 +230,7 @@ If you define these options you will enable the associated feature, which may in * `#define RGBLIGHT_SPLIT` * Needed if both halves of the board have RGB LEDs wired directly to the RGB output pin on the controllers instead of passing the output of the left half to the input of the right half * `#define RGBLED_SPLIT { 6, 6 }` - * number of LEDs connected that are directly wired to `RGB_DI_PIN` on each half of a split keyboard + * number of LEDs connected that are directly wired to the RGB pin on each half of a split keyboard * First value indicates number of LEDs for left half, second value is for the right half * When RGBLED_SPLIT is defined, RGBLIGHT_SPLIT is implicitly defined. * `#define RGBLIGHT_HUE_STEP 12` diff --git a/docs/feature_caps_word.md b/docs/feature_caps_word.md index c58d1a56e2..7f726b059d 100644 --- a/docs/feature_caps_word.md +++ b/docs/feature_caps_word.md @@ -90,6 +90,26 @@ by defining `IS_COMMAND()` in config.h: ## Customizing Caps Word :id=customizing-caps-word +### Invert on shift :id=invert-on-shift + +By default, Caps Word turns off when Shift keys are pressed, considering them as +word-breaking. Alternatively with the `CAPS_WORD_INVERT_ON_SHIFT` option, +pressing the Shift key continues Caps Word and inverts the shift state. This +is convenient for uncapitalizing one or a few letters within a word, for +example with Caps Word on, typing "D, B, Shift+A, Shift+A, S" produces "DBaaS", +or typing "P, D, F, Shift+S" produces "PDFs". + +Enable it by adding in config.h + +```c +#define CAPS_WORD_INVERT_ON_SHIFT +``` + +This option works with regular Shift keys `KC_LSFT` and `KC_RSFT`, mod-tap Shift +keys, and one-shot Shift keys. Note that while Caps Word is on, one-shot Shift +keys behave like regular Shift keys, and have effect only while they are held. + + ### Idle timeout :id=idle-timeout Caps Word turns off automatically if no keys are pressed for diff --git a/docs/feature_converters.md b/docs/feature_converters.md index ec1f3915ee..b1abfa373a 100644 --- a/docs/feature_converters.md +++ b/docs/feature_converters.md @@ -20,11 +20,13 @@ Currently the following converters are available: | `promicro` | `rp2040_ce` | | `promicro` | `elite_pi` | | `promicro` | `helios` | +| `promicro` | `liatris` | | `promicro` | `michi` | | `elite_c` | `stemcell` | | `elite_c` | `rp2040_ce` | | `elite_c` | `elite_pi` | | `elite_c` | `helios` | +| `elite_c` | `liatris` | See below for more in depth information on each converter. @@ -87,6 +89,7 @@ If a board currently supported in QMK uses a [Pro Micro](https://www.sparkfun.co | [customMK Bonsai C4](https://shop.custommk.com/products/bonsai-c4-microcontroller-board) | `bonsai_c4` | | [Elite-Pi](https://keeb.io/products/elite-pi-usb-c-pro-micro-replacement-rp2040) | `elite_pi` | | [0xCB Helios](https://keeb.supply/products/0xcb-helios) | `helios` | +| [Liatris](https://splitkb.com/products/liatris) | `liatris` | | [Michi](https://github.com/ci-bus/michi-promicro-rp2040) | `michi` | Converter summary: @@ -103,6 +106,7 @@ Converter summary: | `rp2040_ce` | `-e CONVERT_TO=rp2040_ce` | `CONVERT_TO=rp2040_ce` | `#ifdef CONVERT_TO_RP2040_CE` | | `elite_pi` | `-e CONVERT_TO=elite_pi` | `CONVERT_TO=elite_pi` | `#ifdef CONVERT_TO_ELITE_PI` | | `helios` | `-e CONVERT_TO=helios` | `CONVERT_TO=helios` | `#ifdef CONVERT_TO_HELIOS` | +| `liatris` | `-e CONVERT_TO=liatris` | `CONVERT_TO=liatris` | `#ifdef CONVERT_TO_LIATRIS` | | `michi` | `-e CONVERT_TO=michi` | `CONVERT_TO=michi` | `#ifdef CONVERT_TO_MICHI` | ### Proton C :id=proton_c @@ -167,7 +171,7 @@ The Bonsai C4 only has one on-board LED (B2), and by default, both the Pro Micro #define B0 PAL_LINE(GPIOA, 9) ``` -### RP2040 Community Edition - Elite-Pi and Helios :id=rp2040_ce +### RP2040 Community Edition - Elite-Pi, Helios, and Liatris :id=rp2040_ce Feature set currently identical to [Adafruit KB2040](#kb2040). @@ -184,6 +188,7 @@ If a board currently supported in QMK uses an [Elite-C](https://keeb.io/products | [STeMCell](https://github.com/megamind4089/STeMCell) | `stemcell` | | [Elite-Pi](https://keeb.io/products/elite-pi-usb-c-pro-micro-replacement-rp2040) | `elite_pi` | | [0xCB Helios](https://keeb.supply/products/0xcb-helios) | `helios` | +| [Liatris](https://splitkb.com/products/liatris) | `liatris` | Converter summary: @@ -193,6 +198,7 @@ Converter summary: | `rp2040_ce` | `-e CONVERT_TO=rp2040_ce` | `CONVERT_TO=rp2040_ce` | `#ifdef CONVERT_TO_RP2040_CE` | | `elite_pi` | `-e CONVERT_TO=elite_pi` | `CONVERT_TO=elite_pi` | `#ifdef CONVERT_TO_ELITE_PI` | | `helios` | `-e CONVERT_TO=helios` | `CONVERT_TO=helios` | `#ifdef CONVERT_TO_HELIOS` | +| `liatris` | `-e CONVERT_TO=liatris` | `CONVERT_TO=liatris` | `#ifdef CONVERT_TO_LIATRIS` | ### STeMCell :id=stemcell_elite diff --git a/docs/feature_dynamic_macros.md b/docs/feature_dynamic_macros.md index f5a6952b6b..8ab1bad61c 100644 --- a/docs/feature_dynamic_macros.md +++ b/docs/feature_dynamic_macros.md @@ -59,7 +59,7 @@ There are a number of hooks that you can use to add custom functionality and fee Note, that direction indicates which macro it is, with `1` being Macro 1, `-1` being Macro 2, and 0 being no macro. -* `dynamic_macro_record_start_user(void)` - Triggered when you start recording a macro. +* `dynamic_macro_record_start_user(int8_t direction)` - Triggered when you start recording a macro. * `dynamic_macro_play_user(int8_t direction)` - Triggered when you play back a macro. * `dynamic_macro_record_key_user(int8_t direction, keyrecord_t *record)` - Triggered on each keypress while recording a macro. * `dynamic_macro_record_end_user(int8_t direction)` - Triggered when the macro recording is stopped. diff --git a/docs/feature_encoders.md b/docs/feature_encoders.md index 1c521a4eff..891baeefa1 100644 --- a/docs/feature_encoders.md +++ b/docs/feature_encoders.md @@ -81,7 +81,7 @@ Your `keymap.c` will then need an encoder mapping defined (for four layers and t ```c #if defined(ENCODER_MAP_ENABLE) -const uint16_t PROGMEM encoder_map[][NUM_ENCODERS][2] = { +const uint16_t PROGMEM encoder_map[][NUM_ENCODERS][NUM_DIRECTIONS] = { [_BASE] = { ENCODER_CCW_CW(KC_MS_WH_UP, KC_MS_WH_DOWN), ENCODER_CCW_CW(KC_VOLD, KC_VOLU) }, [_LOWER] = { ENCODER_CCW_CW(RGB_HUD, RGB_HUI), ENCODER_CCW_CW(RGB_SAD, RGB_SAI) }, [_RAISE] = { ENCODER_CCW_CW(RGB_VAD, RGB_VAI), ENCODER_CCW_CW(RGB_SPD, RGB_SPI) }, @@ -102,9 +102,9 @@ Using encoder mapping pumps events through the normal QMK keycode processing pip ## Callbacks -When not using `ENCODER_MAP_ENABLE = yes`, the callback functions can be inserted into your `<keyboard>.c`: +?> [**Default Behaviour**](https://github.com/qmk/qmk_firmware/blob/master/quantum/encoder.c#L79-#L98): all encoders installed will function as volume up (`KC_VOLU`) on clockwise rotation and volume down (`KC_VOLD`) on counter-clockwise rotation. If you do not wish to override this, no further configuration is necessary. -?> Those who are adding new keyboard support where encoders are enabled at the keyboard level should include basic encoder functionality at the keyboard level (`<keyboard>.c`) using the `encoder_update_kb()` function, that way it works for QMK Configuator users and exists in general. +If you would like the alter the default behaviour, and are not using `ENCODER_MAP_ENABLE = yes`, the callback functions can be inserted into your `<keyboard>.c`: ```c bool encoder_update_kb(uint8_t index, bool clockwise) { @@ -113,9 +113,9 @@ bool encoder_update_kb(uint8_t index, bool clockwise) { } if (index == 0) { /* First encoder */ if (clockwise) { - tap_code_delay(KC_VOLU, 10); + tap_code(KC_PGDN); } else { - tap_code_delay(KC_VOLD, 10); + tap_code(KC_PGUP); } } else if (index == 1) { /* Second encoder */ if (clockwise) { @@ -134,9 +134,9 @@ or `keymap.c`: bool encoder_update_user(uint8_t index, bool clockwise) { if (index == 0) { /* First encoder */ if (clockwise) { - tap_code_delay(KC_VOLU, 10); + tap_code(KC_PGDN); } else { - tap_code_delay(KC_VOLD, 10); + tap_code(KC_PGUP); } } else if (index == 1) { /* Second encoder */ if (clockwise) { @@ -149,7 +149,7 @@ bool encoder_update_user(uint8_t index, bool clockwise) { } ``` -!> If you return `true` in the keymap level `_user` function, it will allow the keyboard level encoder code to run on top of your own. Returning `false` will override the keyboard level function, if setup correctly. This is generally the safest option to avoid confusion. +!> If you return `true` in the keymap level `_user` function, it will allow the keyboard/core level encoder code to run on top of your own. Returning `false` will override the keyboard level function, if setup correctly. This is generally the safest option to avoid confusion. ## Hardware diff --git a/docs/feature_layers.md b/docs/feature_layers.md index f8cb53eda4..8503603ffe 100644 --- a/docs/feature_layers.md +++ b/docs/feature_layers.md @@ -127,6 +127,54 @@ layer_state_t layer_state_set_user(layer_state_t state) { } ``` +### Example: Keycode to cycle through layers + +This example shows how to implement a custom keycode to cycle through a range of layers. + +```c +// Define the keycode, `QK_USER` avoids collisions with existing keycodes +enum keycodes { + KC_CYCLE_LAYERS = QK_USER, +}; + +// 1st layer on the cycle +#define LAYER_CYCLE_START 0 +// Last layer on the cycle +#define LAYER_CYCLE_END 4 + +// Add the behaviour of this new keycode +bool process_record_user(uint16_t keycode, keyrecord_t *record) { + switch (keycode) { + case KC_CYCLE_LAYERS: + // Our logic will happen on presses, nothing is done on releases + if (!record->event.pressed) { + // We've already handled the keycode (doing nothing), let QMK know so no further code is run unnecessarily + return false; + } + + uint8_t current_layer = get_highest_layer(layer_state); + + // Check if we are within the range, if not quit + if (curent_layer > LAYER_CYCLE_END || current_layer < LAYER_CYCLE_START) { + return false; + } + + uint8_t next_layer = current_layer + 1; + if (next_layer > LAYER_CYCLE_END) { + next_layer = LAYER_CYCLE_START; + } + layer_move(next_layer); + return false; + + // Process other keycodes normally + default: + return true; + } +} + +// Place `KC_CYCLE_LAYERS` as a keycode in your keymap +``` + Use the `IS_LAYER_ON_STATE(state, layer)` and `IS_LAYER_OFF_STATE(state, layer)` macros to check the status of a particular layer. Outside of `layer_state_set_*` functions, you can use the `IS_LAYER_ON(layer)` and `IS_LAYER_OFF(layer)` macros to check global layer state. diff --git a/docs/feature_led_matrix.md b/docs/feature_led_matrix.md index 1cde9b66e1..bc86099f1f 100644 --- a/docs/feature_led_matrix.md +++ b/docs/feature_led_matrix.md @@ -378,13 +378,7 @@ For inspiration and examples, check out the built-in effects under `quantum/led_ ## EEPROM storage :id=eeprom-storage -The EEPROM for it is currently shared with the RGB Matrix system (it's generally assumed only one feature would be used at a time), but could be configured to use its own 32bit address with: - -```c -#define EECONFIG_LED_MATRIX (uint32_t *)28 -``` - -Where `28` is an unused index from `eeconfig.h`. +The EEPROM for it is currently shared with the RGB Matrix system (it's generally assumed only one feature would be used at a time). ### Direct Operation :id=direct-operation |Function |Description | diff --git a/docs/feature_pointing_device.md b/docs/feature_pointing_device.md index 4da5d64a1a..909eff826d 100644 --- a/docs/feature_pointing_device.md +++ b/docs/feature_pointing_device.md @@ -197,6 +197,24 @@ The Pimoroni Trackball module is a I2C based breakout board with an RGB enable t | `PIMORONI_TRACKBALL_DEBOUNCE_CYCLES` | (Optional) The number of scan cycles used for debouncing on the ball press. | `20` | | `PIMORONI_TRACKBALL_ERROR_COUNT` | (Optional) Specifies the number of read/write errors until the sensor is disabled. | `10` | +### PMW3320 Sensor + +To use the PMW3320 sensor, add this to your `rules.mk` + +```make +POINTING_DEVICE_DRIVER = pmw3320 +``` + +The PMW3320 sensor uses a serial type protocol for communication, and requires an additional light source (it could work without one, but expect it to be out of service early). + +| Setting | Description | Default | +| ------------------- | ------------------------------------------------------------------- | -------------------------- | +| `PMW3320_SCLK_PIN` | (Required) The pin connected to the clock pin of the sensor. | `POINTING_DEVICE_SCLK_PIN` | +| `PMW3320_SDIO_PIN` | (Required) The pin connected to the data pin of the sensor. | `POINTING_DEVICE_SDIO_PIN` | +| `PMW3320_CS_PIN` | (Required) The pin connected to the cable select pin of the sensor. | `POINTING_DEVICE_CS_PIN` | + +The CPI range is 500-3500, in increments of 250. Defaults to 1000 CPI. + ### PMW 3360 and PMW 3389 Sensor This drivers supports both the PMW 3360 and PMW 3389 sensor as well as multiple sensors of the same type _per_ controller, so 2 can be attached at the same side for split keyboards (or unsplit keyboards). @@ -671,6 +689,10 @@ There are several functions that allow for more advanced interaction with the au | `auto_mouse_layer_off(void)` | Disable target layer if appropriate will call (makes call to `layer_state_set`) | | `void`(None) | | `auto_mouse_toggle(void)` | Toggle on/off target toggle state (disables layer deactivation when true) | | `void`(None) | | `get_auto_mouse_toggle(void)` | Return value of toggling state variable | | `bool` | +| `set_auto_mouse_timeout(uint16_t timeout)` | Change/set the timeout for turing off the layer | | `void`(None) | +| `get_auto_mouse_timeout(void)` | Return the current timeout for turing off the layer | | `uint16_t` | +| `set_auto_mouse_debounce(uint16_t timeout)` | Change/set the debounce for preventing layer activation | | `void`(None) | +| `get_auto_mouse_debounce(void)` | Return the current debounce for preventing layer activation | | `uint8_t` | _NOTES:_ - _Due to the nature of how some functions work, the `auto_mouse_trigger_reset`, and `auto_mouse_layer_off` functions should never be called in the `layer_state_set_*` stack as this can cause indefinite loops._ @@ -782,7 +804,7 @@ _Note: The Cirque pinnacle track pad already implements a custom activation func When using a custom pointing device (overwriting `pointing_device_task`) the following code should be somewhere in the `pointing_device_task_*` stack: ```c -void pointing_device_task(void) { +bool pointing_device_task(void) { //...Custom pointing device task code // handle automatic mouse layer (needs report_mouse_t as input) @@ -790,7 +812,7 @@ void pointing_device_task(void) { //...More custom pointing device task code - pointing_device_send(); + return pointing_device_send(); } ``` diff --git a/docs/feature_rgb_matrix.md b/docs/feature_rgb_matrix.md index 20ad4c7faf..75f07b5e64 100644 --- a/docs/feature_rgb_matrix.md +++ b/docs/feature_rgb_matrix.md @@ -156,6 +156,82 @@ const is31_led PROGMEM g_is31_leds[RGB_MATRIX_LED_COUNT] = { Where `X_Y` is the location of the LED in the matrix defined by [the datasheet](https://www.issi.com/WW/pdf/31FL3733.pdf) and the header file `drivers/led/issi/is31fl3733.h`. The `driver` is the index of the driver you defined in your `config.h` (`0`, `1`, `2`, or `3` for now). --- +### IS31FL3736 :id=is31fl3736 + +There is basic support for addressable RGB matrix lighting with the I2C IS31FL3736 RGB controller. To enable it, add this to your `rules.mk`: + +```make +RGB_MATRIX_ENABLE = yes +RGB_MATRIX_DRIVER = IS31FL3736 +``` +You can use between 1 and 4 IS31FL3736 IC's. Do not specify `DRIVER_ADDR_<N>` defines for IC's that are not present on your keyboard. + +Configure the hardware via your `config.h`: + +| Variable | Description | Default | +|----------|-------------|---------| +| `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages, in milliseconds | 100 | +| `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 | +| `ISSI_PWM_FREQUENCY` | (Optional) PWM Frequency Setting - IS31FL3736B only | 0 | +| `ISSI_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF | +| `ISSI_SWPULLUP` | (Optional) Set the value of the SWx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | +| `ISSI_CSPULLUP` | (Optional) Set the value of the CSx lines on-chip de-ghosting resistors | PUR_0R (Disabled) | +| `DRIVER_COUNT` | (Required) How many RGB driver IC's are present | | +| `RGB_MATRIX_LED_COUNT` | (Required) How many RGB lights are present across all drivers | | +| `DRIVER_ADDR_1` | (Required) Address for the first RGB driver | | +| `DRIVER_ADDR_2` | (Optional) Address for the second RGB driver | | +| `DRIVER_ADDR_3` | (Optional) Address for the third RGB driver | | +| `DRIVER_ADDR_4` | (Optional) Address for the fourth RGB driver | | + +The IS31FL3736 IC's have on-chip resistors that can be enabled to allow for de-ghosting of the RGB matrix. By default these resistors are not enabled (`ISSI_SWPULLUP`/`ISSI_CSPULLUP` are given the value of`PUR_0R`), the values that can be set to enable de-ghosting are as follows: + +| `ISSI_SWPULLUP/ISSI_CSPULLUP` | Description | +|----------------------|-------------| +| `PUR_0R` | (default) Do not use the on-chip resistors/enable de-ghosting | +| `PUR_05KR` | The 0.5k Ohm resistor used during blanking period (t_NOL) | +| `PUR_1KR` | The 1k Ohm resistor used during blanking period (t_NOL) | +| `PUR_2KR` | The 2k Ohm resistor used during blanking period (t_NOL) | +| `PUR_4KR` | The 4k Ohm resistor used during blanking period (t_NOL) | +| `PUR_8KR` | The 8k Ohm resistor during blanking period (t_NOL) | +| `PUR_16KR` | The 16k Ohm resistor during blanking period (t_NOL) | +| `PUR_32KR` | The 32k Ohm resistor used during blanking period (t_NOL) | + +Here is an example using 2 drivers. + +```c +// This is a 7-bit address, that gets left-shifted and bit 0 +// set to 0 for write, 1 for read (as per I2C protocol) +// The address will vary depending on your wiring: +// 0000 <-> GND +// 0101 <-> SCL +// 1010 <-> SDA +// 1111 <-> VCC +// ADDR represents A3:A0 of the 7-bit address. +// The result is: 0b101(ADDR) +#define DRIVER_ADDR_1 0b1010000 +#define DRIVER_ADDR_2 0b1010001 + +#define DRIVER_COUNT 2 +#define DRIVER_1_LED_TOTAL 30 +#define DRIVER_2_LED_TOTAL 32 +#define RGB_MATRIX_LED_COUNT (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL) +``` +!> Note the parentheses, this is so when `RGB_MATRIX_LED_COUNT` is used in code and expanded, the values are added together before any additional math is applied to them. As an example, `rand() % (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL)` will give very different results than `rand() % DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL`. + +Define these arrays listing all the LEDs in your `<keyboard>.c`: + +```c +const is31_led PROGMEM g_is31_leds[RGB_MATRIX_LED_COUNT] = { +/* Refer to IS31 manual for these locations + * driver + * | R location + * | | G location + * | | | B location + * | | | | */ + {0, B_1, A_1, C_1}, + .... +} +``` ### IS31FL3737 :id=is31fl3737 There is basic support for addressable RGB matrix lighting with the I2C IS31FL3737 RGB controller. To enable it, add this to your `rules.mk`: @@ -218,8 +294,6 @@ Here is an example using 2 drivers. ``` !> Note the parentheses, this is so when `RGB_MATRIX_LED_COUNT` is used in code and expanded, the values are added together before any additional math is applied to them. As an example, `rand() % (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL)` will give very different results than `rand() % DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL`. -Currently only 2 drivers are supported, but it would be trivial to support all 4 combinations. - Define these arrays listing all the LEDs in your `<keyboard>.c`: ```c @@ -361,7 +435,7 @@ Configure the hardware via your `config.h`: ```c // The pin connected to the data pin of the LEDs -#define RGB_DI_PIN D7 +#define WS2812_DI_PIN D7 // The number of LEDs connected #define RGB_MATRIX_LED_COUNT 70 ``` @@ -383,9 +457,9 @@ Configure the hardware via your `config.h`: ```c // The pin connected to the data pin of the LEDs -#define RGB_DI_PIN D7 +#define APA102_DI_PIN D7 // The pin connected to the clock pin of the LEDs -#define RGB_CI_PIN D6 +#define APA102_CI_PIN D6 // The number of LEDs connected #define RGB_MATRIX_LED_COUNT 70 ``` @@ -690,6 +764,14 @@ Remove the spread effect entirely. #define RGB_MATRIX_TYPING_HEATMAP_SLIM ``` +It's also possible to adjust the tempo of *heating up*. It's defined as the number of shades that are +increased on the [HSV scale](https://en.wikipedia.org/wiki/HSL_and_HSV). Decreasing this value increases +the number of keystrokes needed to fully heat up the key. + +```c +#define RGB_MATRIX_TYPING_HEATMAP_INCREASE_STEP 32 +``` + ### RGB Matrix Effect Solid Reactive :id=rgb-matrix-effect-solid-reactive Solid reactive effects will pulse RGB light on key presses with user configurable hues. To enable gradient mode that will automatically change reactive color, add the following define: @@ -811,13 +893,7 @@ These are defined in [`color.h`](https://github.com/qmk/qmk_firmware/blob/master ## EEPROM storage :id=eeprom-storage -The EEPROM for it is currently shared with the LED Matrix system (it's generally assumed only one feature would be used at a time), but could be configured to use its own 32bit address with: - -```c -#define EECONFIG_RGB_MATRIX (uint32_t *)28 -``` - -Where `28` is an unused index from `eeconfig.h`. +The EEPROM for it is currently shared with the LED Matrix system (it's generally assumed only one feature would be used at a time). ## Functions :id=functions diff --git a/docs/feature_rgblight.md b/docs/feature_rgblight.md index 060efaf1b3..5131658ae1 100644 --- a/docs/feature_rgblight.md +++ b/docs/feature_rgblight.md @@ -33,12 +33,13 @@ RGBLIGHT_DRIVER = APA102 At minimum you must define the data pin your LED strip is connected to, and the number of LEDs in the strip, in your `config.h`. For APA102 LEDs, you must also define the clock pin. If your keyboard has onboard RGB LEDs, and you are simply creating a keymap, you usually won't need to modify these. -|Define |Description | -|---------------|---------------------------------------------------------------------------------------------------------| -|`RGB_DI_PIN` |The pin connected to the data pin of the LEDs | -|`RGB_CI_PIN` |The pin connected to the clock pin of the LEDs (APA102 only) | -|`RGBLED_NUM` |The number of LEDs connected | -|`RGBLED_SPLIT` |(Optional) For split keyboards, the number of LEDs connected on each half directly wired to `RGB_DI_PIN` | +|Define |Description | +|---------------|-------------------------------------------------------------------------| +|`WS2812_DI_PIN`|The pin connected to the data pin of the LEDs (WS2812) | +|`APA102_DI_PIN`|The pin connected to the data pin of the LEDs (APA102) | +|`APA102_CI_PIN`|The pin connected to the clock pin of the LEDs (APA102) | +|`RGBLED_NUM` |The number of LEDs connected | +|`RGBLED_SPLIT` |(Optional) For split keyboards, the number of LEDs connected on each half| Then you should be able to use the keycodes below to change the RGB lighting to your liking. diff --git a/docs/feature_split_keyboard.md b/docs/feature_split_keyboard.md index c095c8712f..1705ea9222 100644 --- a/docs/feature_split_keyboard.md +++ b/docs/feature_split_keyboard.md @@ -300,6 +300,12 @@ This enables transmitting the pointing device status to the master side of the s This enables triggering of haptic feedback on the slave side of the split keyboard. For DRV2605L this will send the mode, but for solenoids it is expected that the desired mode is already set up on the slave. +```c +#define SPLIT_ACTIVITY_ENABLE +``` + +This synchronizes the activity timestamps between sides of the split keyboard, allowing for activity timeouts to occur. + ### Custom data sync between sides :id=custom-data-sync QMK's split transport allows for arbitrary data transactions at both the keyboard and user levels. This is modelled on a remote procedure call, with the master invoking a function on the slave side, with the ability to send data from master to slave, process it slave side, and send data back from slave to master. diff --git a/docs/feature_stenography.md b/docs/feature_stenography.md index 62d4dabf81..df4c9c6ad3 100644 --- a/docs/feature_stenography.md +++ b/docs/feature_stenography.md @@ -138,7 +138,7 @@ bool post_process_steno_user(uint16_t keycode, keyrecord_t *record, steno_mode_t This function is called after a key has been processed, but before any decision about whether or not to send a chord. This is where to put hooks for things like, say, live displays of steno chords or keys. -If `IS_PRESSED(record->event)` is false, and `n_pressed_keys` is 0 or 1, the chord will be sent shortly, but has not yet been sent. This relieves you of the need of keeping track of where a packet ends and another begins. +If `record->event.pressed` is false, and `n_pressed_keys` is 0 or 1, the chord will be sent shortly, but has not yet been sent. This relieves you of the need of keeping track of where a packet ends and another begins. The `chord` argument contains the packet of the current chord as specified by the protocol in use. This is *NOT* simply a list of chorded steno keys of the form `[STN_E, STN_U, STN_BR, STN_GR]`. Refer to the appropriate protocol section of this document to learn more about the format of the packets in your steno protocol/mode of choice. diff --git a/docs/feature_swap_hands.md b/docs/feature_swap_hands.md index 4d0d554093..e9c1d4b7ba 100644 --- a/docs/feature_swap_hands.md +++ b/docs/feature_swap_hands.md @@ -47,6 +47,11 @@ const uint8_t PROGMEM encoder_hand_swap_config[NUM_ENCODERS] = { 1, 0 }; ### Functions :id=functions -| Function | Description | -|----------------------|---------------------------------------------| -| `is_swap_hands_on()` | Returns true if Swap-Hands is currently on. | +User callback functions to manipulate Swap-Hands: + +| Function | Description | +|-----------------------|---------------------------------------------| +| `swap_hands_on()` | Turns Swap-Hands on. | +| `swap_hands_off()` | Turns Swap-Hands off. | +| `swap_hands_toggle()` | Toggles Swap-Hands. | +| `is_swap_hands_on()` | Returns true if Swap-Hands is currently on. | diff --git a/docs/getting_started_vagrant.md b/docs/getting_started_vagrant.md deleted file mode 100644 index b5b5ce1539..0000000000 --- a/docs/getting_started_vagrant.md +++ /dev/null @@ -1,56 +0,0 @@ -# Vagrant Quick Start - -This project includes a `Vagrantfile` that will allow you to build a new firmware for your keyboard very easily without major changes to your primary operating system. This also ensures that when you clone the project and perform a build, you have the exact same environment as anyone else using the Vagrantfile to build. This makes it much easier for people to help you troubleshoot any issues you encounter. - |