diff options
Diffstat (limited to 'docs')
29 files changed, 698 insertions, 284 deletions
diff --git a/docs/ChangeLog/20220226/PR15304.md b/docs/ChangeLog/20220226/PR15304.md new file mode 100644 index 0000000000..3cdb40db10 --- /dev/null +++ b/docs/ChangeLog/20220226/PR15304.md @@ -0,0 +1,13 @@ +### Split Common core now supports Pointing Devices ([#15304](https://github.com/qmk/qmk_firmware/pull/15304)) + +Pointing devices can now be shared across a split keyboard with support for a single pointing device or a pointing device on each side. + +This feature can be enabled with `#define SPLIT_POINTING_ENABLE` and one of the following options: + +| Setting | Description | +|---------------------------|------------------------------------| +|`POINTING_DEVICE_LEFT` | Pointing device on the left side | +|`POINTING_DEVICE_RIGHT` | Pointing device on the right side | +|`POINTING_DEVICE_COMBINED` | Pointing device on both sides | + +See the [Pointing Device](../feature_pointing_device.md) documentation for further configuration options. diff --git a/docs/_summary.md b/docs/_summary.md index e26d9ae210..8c83a216ab 100644 --- a/docs/_summary.md +++ b/docs/_summary.md @@ -37,7 +37,6 @@ * Guides * [Customizing Functionality](custom_quantum_functions.md) * [Driver Installation with Zadig](driver_installation_zadig.md) - * [Easy Maker for One Offs](easy_maker.md) * [Keymap Overview](keymap.md) * Development Environments * [Docker Guide](getting_started_docker.md) @@ -53,9 +52,6 @@ * [Your Fork](newbs_git_using_your_master_branch.md) * [Merge Conflicts](newbs_git_resolving_merge_conflicts.md) * [Fixing Your Branch](newbs_git_resynchronize_a_branch.md) - * Keyboard Building - * [Hand Wiring Guide](hand_wire.md) - * [ISP Flashing Guide](isp_flashing_guide.md) * Simple Keycodes * [Full List](keycodes.md) @@ -124,6 +120,12 @@ * [Thermal Printer](feature_thermal_printer.md) * [Velocikey](feature_velocikey.md) + * Keyboard Building + * [Easy Maker for One Offs](easy_maker.md) + * [Porting Keyboards](porting_your_keyboard_to_qmk.md) + * [Hand Wiring Guide](hand_wire.md) + * [ISP Flashing Guide](isp_flashing_guide.md) + * Developing QMK * [PR Checklist](pr_checklist.md) * Breaking Changes @@ -134,7 +136,6 @@ * C Development * [ARM Debugging Guide](arm_debugging.md) - * [AVR Processors](hardware_avr.md) * [Coding Conventions](coding_conventions_c.md) * [Compatible Microcontrollers](compatible_microcontrollers.md) * [Drivers](hardware_drivers.md) diff --git a/docs/cli_commands.md b/docs/cli_commands.md index dfbd4c6a28..93af906b8a 100644 --- a/docs/cli_commands.md +++ b/docs/cli_commands.md @@ -310,7 +310,7 @@ Any arguments that are not provided will prompt for input. If `-u` is not passed **Usage**: ``` -qmk new-keyboard [-kb KEYBOARD] [-t {avr,ps2avrgb}] -u USERNAME +qmk new-keyboard [-kb KEYBOARD] [-t {atmega32u4,STM32F303,etc}] [-l {60_ansi,75_iso,etc}] -u USERNAME ``` ## `qmk new-keymap` diff --git a/docs/compatible_microcontrollers.md b/docs/compatible_microcontrollers.md index 1f46a1c634..1c5e37f724 100644 --- a/docs/compatible_microcontrollers.md +++ b/docs/compatible_microcontrollers.md @@ -1,6 +1,6 @@ # Compatible Microcontrollers -QMK runs on any USB-capable AVR or ARM microcontroller with enough flash space - generally 32kB or more, though it will *just* squeeze into 16kB with most features disabled. +QMK runs on any USB-capable AVR or ARM microcontroller with enough flash space - generally 32kB+ for AVR, and 64kB+ for ARM. With significant disabling of features, QMK may *just* squeeze into 16kB AVR MCUs. ## Atmel AVR @@ -8,7 +8,11 @@ The following use [LUFA](https://www.fourwalledcubicle.com/LUFA.php) as the USB * [ATmega16U2](https://www.microchip.com/wwwproducts/en/ATmega16U2) / [ATmega32U2](https://www.microchip.com/wwwproducts/en/ATmega32U2) * [ATmega16U4](https://www.microchip.com/wwwproducts/en/ATmega16U4) / [ATmega32U4](https://www.microchip.com/wwwproducts/en/ATmega32U4) + * SparkFun Pro Micro (and clones) + * PJRC Teensy 2.0 + * Adafruit Feather 32U4 * [AT90USB64](https://www.microchip.com/wwwproducts/en/AT90USB646) / [AT90USB128](https://www.microchip.com/wwwproducts/en/AT90USB1286) + * PJRC Teensy++ 2.0 * [AT90USB162](https://www.microchip.com/wwwproducts/en/AT90USB162) Certain MCUs which do not have native USB will use [V-USB](https://www.obdev.at/products/vusb/index.html) instead: @@ -25,17 +29,23 @@ You can also use any ARM chip with USB that [ChibiOS](https://www.chibios.org) s * [STM32F0x2](https://www.st.com/en/microcontrollers-microprocessors/stm32f0x2.html) * [STM32F103](https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html) + * Bluepill (with STM32duino bootloader) * [STM32F303](https://www.st.com/en/microcontrollers-microprocessors/stm32f303.html) + * QMK Proton-C * [STM32F401](https://www.st.com/en/microcontrollers-microprocessors/stm32f401.html) + * WeAct Blackpill * [STM32F405](https://www.st.com/en/microcontrollers-microprocessors/stm32f405-415.html) * [STM32F407](https://www.st.com/en/microcontrollers-microprocessors/stm32f407-417.html) * [STM32F411](https://www.st.com/en/microcontrollers-microprocessors/stm32f411.html) + * WeAct Blackpill * [STM32F446](https://www.st.com/en/microcontrollers-microprocessors/stm32f446.html) * [STM32G431](https://www.st.com/en/microcontrollers-microprocessors/stm32g4x1.html) * [STM32G474](https://www.st.com/en/microcontrollers-microprocessors/stm32g4x4.html) * [STM32L412](https://www.st.com/en/microcontrollers-microprocessors/stm32l4x2.html) * [STM32L422](https://www.st.com/en/microcontrollers-microprocessors/stm32l4x2.html) + * [STM32L432](https://www.st.com/en/microcontrollers-microprocessors/stm32l4x2.html) * [STM32L433](https://www.st.com/en/microcontrollers-microprocessors/stm32l4x3.html) + * [STM32L442](https://www.st.com/en/microcontrollers-microprocessors/stm32l4x2.html) * [STM32L443](https://www.st.com/en/microcontrollers-microprocessors/stm32l4x3.html) ### WestBerryTech (WB32) @@ -45,13 +55,16 @@ You can also use any ARM chip with USB that [ChibiOS](https://www.chibios.org) s ### NXP (Kinetis) * [MKL26Z64](https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/kl-series-cortex-m0-plus/kinetis-kl2x-72-96-mhz-usb-ultra-low-power-microcontrollers-mcus-based-on-arm-cortex-m0-plus-core:KL2x) + * PJRC Teensy LC * [MK20DX128](https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/k-series-cortex-m4/k2x-usb/kinetis-k20-50-mhz-full-speed-usb-mixed-signal-integration-microcontrollers-based-on-arm-cortex-m4-core:K20_50) * [MK20DX256](https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/k-series-cortex-m4/k2x-usb/kinetis-k20-72-mhz-full-speed-usb-mixed-signal-integration-microcontrollers-mcus-based-on-arm-cortex-m4-core:K20_72) + * PJRC Teensy 3.2 * [MK66FX1M0](https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/k-series-cortex-m4/k6x-ethernet/kinetis-k66-180-mhz-dual-high-speed-full-speed-usbs-2mb-flash-microcontrollers-mcus-based-on-arm-cortex-m4-core:K66_180) + * PJRC Teensy 3.6 ## Atmel ATSAM -There is limited support for one of Atmel's ATSAM microcontrollers, that being the [ATSAMD51J18A](https://www.microchip.com/wwwproducts/en/ATSAMD51J18A) used by the [Massdrop keyboards](https://github.com/qmk/qmk_firmware/tree/master/keyboards/massdrop). +There is limited support for one of Atmel's ATSAM microcontrollers, that being the [ATSAMD51J18A](https://www.microchip.com/wwwproducts/en/ATSAMD51J18A) used by the [Massdrop keyboards](https://github.com/qmk/qmk_firmware/tree/master/keyboards/massdrop). However, it is not recommended to design a board with this microcontroller as the support is quite specialized to Massdrop hardware. ## RISC-V diff --git a/docs/config_options.md b/docs/config_options.md index 15ad945b22..838c4d86fd 100644 --- a/docs/config_options.md +++ b/docs/config_options.md @@ -126,10 +126,6 @@ If you define these options you will disable the associated feature, which can s * disable tap dance and other tapping features * `#define NO_ACTION_ONESHOT` * disable one-shot modifiers -* `#define NO_ACTION_MACRO` - * disable old-style macro handling using `MACRO()`, `action_get_macro()` _(deprecated)_ -* `#define NO_ACTION_FUNCTION` - * disable old-style function handling using `fn_actions`, `action_function()` _(deprecated)_ ## Features That Can Be Enabled @@ -385,7 +381,6 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i * A list of [layouts](feature_layouts.md) this keyboard supports. * `LTO_ENABLE` * Enables Link Time Optimization (LTO) when compiling the keyboard. This makes the process take longer, but it can significantly reduce the compiled size (and since the firmware is small, the added time is not noticeable). -However, this will automatically disable the legacy TMK Macros and Functions features, as these break when LTO is enabled. It does this by automatically defining `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION`. (Note: This does not affect QMK [Macros](feature_macros.md) and [Layers](feature_layers.md).) ## AVR MCU Options * `MCU = atmega32u4` @@ -436,8 +431,8 @@ Use these to enable or disable building certain features. The more you have enab * MIDI controls * `UNICODE_ENABLE` * Unicode -* `BLUETOOTH` - * Current options are AdafruitBLE, RN42 +* `BLUETOOTH_ENABLE` + * Current options are BluefruitLE, RN42 * `SPLIT_KEYBOARD` * Enables split keyboard support (dual MCU like the let's split and bakingpy's boards) and includes all necessary files located at quantum/split_common * `CUSTOM_MATRIX` diff --git a/docs/feature_bluetooth.md b/docs/feature_bluetooth.md index f6fb02d948..d4ed494053 100644 --- a/docs/feature_bluetooth.md +++ b/docs/feature_bluetooth.md @@ -7,7 +7,7 @@ Currently Bluetooth support is limited to AVR based chips. For Bluetooth 2.1, QM |Board |Bluetooth Protocol |Connection Type|rules.mk |Bluetooth Chip| |----------------------------------------------------------------|--------------------|---------------|--------------------------------|--------------| |Roving Networks RN-42 (Sparkfun Bluesmirf) |Bluetooth Classic |UART |`BLUETOOTH_DRIVER = RN42` |RN-42 | -|[Bluefruit LE SPI Friend](https://www.adafruit.com/product/2633)|Bluetooth Low Energy|SPI |`BLUETOOTH_DRIVER = AdafruitBLE`|nRF51822 | +|[Bluefruit LE SPI Friend](https://www.adafruit.com/product/2633)|Bluetooth Low Energy|SPI |`BLUETOOTH_DRIVER = BluefruitLE`|nRF51822 | Not Supported Yet but possible: * [Bluefruit LE UART Friend](https://www.adafruit.com/product/2479). [Possible tmk implementation found in](https://github.com/tmk/tmk_keyboard/issues/514) @@ -17,9 +17,9 @@ Not Supported Yet but possible: ### Adafruit BLE SPI Friend Currently The only bluetooth chipset supported by QMK is the Adafruit Bluefruit SPI Friend. It's a Nordic nRF51822 based chip running Adafruit's custom firmware. Data is transmitted via Adafruit's SDEP over Hardware SPI. The [Feather 32u4 Bluefruit LE](https://www.adafruit.com/product/2829) is supported as it's an AVR mcu connected via SPI to the Nordic BLE chip with Adafruit firmware. If Building a custom board with the SPI friend it would be easiest to just use the pin selection that the 32u4 feather uses but you can change the pins in the config.h options with the following defines: -* `#define ADAFRUIT_BLE_RST_PIN D4` -* `#define ADAFRUIT_BLE_CS_PIN B4` -* `#define ADAFRUIT_BLE_IRQ_PIN E6` +* `#define BLUEFRUIT_LE_RST_PIN D4` +* `#define BLUEFRUIT_LE_CS_PIN B4` +* `#define BLUEFRUIT_LE_IRQ_PIN E6` A Bluefruit UART friend can be converted to an SPI friend, however this [requires](https://github.com/qmk/qmk_firmware/issues/2274) some reflashing and soldering directly to the MDBT40 chip. @@ -32,7 +32,7 @@ Add the following to your `rules.mk`: ```make BLUETOOTH_ENABLE = yes -BLUETOOTH_DRIVER = AdafruitBLE # or RN42 +BLUETOOTH_DRIVER = BluefruitLE # or RN42 ``` ## Bluetooth Keycodes diff --git a/docs/feature_combo.md b/docs/feature_combo.md index 47128c431b..c0e10f09d5 100644 --- a/docs/feature_combo.md +++ b/docs/feature_combo.md @@ -141,10 +141,13 @@ Processing combos has two buffers, one for the key presses, another for the comb ## Modifier Combos If a combo resolves to a Modifier, the window for processing the combo can be extended independently from normal combos. By default, this is disabled but can be enabled with `#define COMBO_MUST_HOLD_MODS`, and the time window can be configured with `#define COMBO_HOLD_TERM 150` (default: `TAPPING_TERM`). With `COMBO_MUST_HOLD_MODS`, you cannot tap the combo any more which makes the combo less prone to misfires. -## Per Combo Timing, Holding and Tapping -For each combo, it is possible to configure the time window it has to pressed in, if it needs to be held down, or if it needs to be tapped. +## Strict key press order +By defining `COMBO_MUST_PRESS_IN_ORDER` combos only activate when the keys are pressed in the same order as they are defined in the key array. -For example, tap-only combos are useful if any (or all) of the underlying keys is a Mod-Tap or a Layer-Tap key. When you tap the combo, you get the combo result. When you press the combo and hold it down, the combo doesn't actually activate. Instead the keys are processed separately as if the combo wasn't even there. +## Per Combo Timing, Holding, Tapping and Key Press Order +For each combo, it is possible to configure the time window it has to pressed in, if it needs to be held down, if it needs to be tapped, or if its keys need to be pressed in order. + +For example, tap-only combos are useful if any (or all) of the underlying keys are mod-tap or layer-tap keys. When you tap the combo, you get the combo result. When you press the combo and hold it down, the combo doesn't activate. Instead the keys are processed separately as if the combo wasn't even there. In order to use these features, the following configuration options and functions need to be defined. Coming up with useful timings and configuration is left as an exercise for the reader. @@ -153,6 +156,7 @@ In order to use these features, the following configuration options and function | `COMBO_TERM_PER_COMBO` | uint16_t get_combo_term(uint16_t index, combo_t \*combo) | Optional per-combo timeout window. (default: `COMBO_TERM`) | | `COMBO_MUST_HOLD_PER_COMBO` | bool get_combo_must_hold(uint16_t index, combo_t \*combo) | Controls if a given combo should fire immediately on tap or if it needs to be held. (default: `false`) | | `COMBO_MUST_TAP_PER_COMBO` | bool get_combo_must_tap(uint16_t index, combo_t \*combo) | Controls if a given combo should fire only if tapped within `COMBO_HOLD_TERM`. (default: `false`) | +| `COMBO_MUST_PRESS_IN_ORDER_PER_COMBO` | bool get_combo_must_press_in_order(uint16_t index, combo_t \*combo) | Controls if a given combo should fire only if its keys are pressed in order. (default: `true`) | Examples: ```c @@ -216,6 +220,38 @@ bool get_combo_must_tap(uint16_t index, combo_t *combo) { return false; } + +bool get_combo_must_press_in_order(uint16_t combo_index, combo_t *combo) { + switch (combo_index) { + /* List combos here that you want to only activate if their keys + * are pressed in the same order as they are defined in the combo's key + * array. */ + case COMBO_NAME_HERE: + return true; + default: + return false; + } +} +``` + +## Generic hook to (dis)allow a combo activation + +By defining `COMBO_SHOULD_TRIGGER` and its companying function `bool combo_should_trigger(uint16_t combo_index, combo_t *combo, uint16_t keycode, keyrecord_t *record)` you can block or allow combos to activate on the conditions of your choice. +For example, you could disallow some combos on the base layer and allow them on another. Or disable combos on the home row when a timer is running. + +Examples: +```c +bool combo_should_trigger(uint16_t combo_index, combo_t *combo, uint16_t keycode, keyrecord_t *record) { + /* Disable combo `SOME_COMBO` on layer `_LAYER_A` */ + switch (combo_index) { + case SOME_COMBO: + if (layer_state_is(_LAYER_A)) { + return false; + } + } + + return true; +} ``` ## Variable Length Combos diff --git a/docs/feature_debounce_type.md b/docs/feature_debounce_type.md index f37a785b1e..9cd736a24a 100644 --- a/docs/feature_debounce_type.md +++ b/docs/feature_debounce_type.md @@ -116,6 +116,7 @@ Where name of algorithm is one of: For use in keyboards where refreshing ```NUM_KEYS``` 8-bit counters is computationally expensive / low scan rate, and fingers usually only hit one row at a time. This could be appropriate for the ErgoDox models; the matrix is rotated 90°, and hence its "rows" are really columns, and each finger only hits a single "row" at a time in normal use. * ```sym_eager_pk``` - debouncing per key. On any state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that key +* ```sym_defer_pr``` - debouncing per row. On any state change, a per-row timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that row, the entire row is pushed. Can improve responsiveness over `sym_defer_g` while being less susceptible than per-key debouncers to noise. * ```sym_defer_pk``` - debouncing per key. On any state change, a per-key timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that key, the key status change is pushed. * ```asym_eager_defer_pk``` - debouncing per key. On a key-down state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that key. On a key-up state change, a per-key timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that key, the key-up status change is pushed. diff --git a/docs/feature_grave_esc.md b/docs/feature_grave_esc.md index f135b1dede..09d098ee4e 100644 --- a/docs/feature_grave_esc.md +++ b/docs/feature_grave_esc.md @@ -4,17 +4,17 @@ If you're using a 60% keyboard, or any other layout with no F-row, you will have ## Usage -Replace the `KC_GRV` key in your keymap (usually to the left of the `1` key) with `KC_GESC`. Most of the time this key will output `KC_ESC` when pressed. However, when Shift or GUI are held down it will output `KC_GRV` instead. +Replace the `KC_GRV` key in your keymap (usually to the left of the `1` key) with `QK_GESC`. Most of the time this key will output `KC_ESC` when pressed. However, when Shift or GUI are held down it will output `KC_GRV` instead. ## What Your OS Sees -If Mary presses GESC on her keyboard, the OS will see an KC_ESC character. Now if Mary holds Shift down and presses GESC it will output `~`, or a shifted backtick. Now if she holds GUI/CMD/WIN, it will output a simple <code>`</code> character. +If Mary presses `QK_GESC` on her keyboard, the OS will see an KC_ESC character. Now if Mary holds Shift down and presses `QK_GESC` it will output `~`, or a shifted backtick. Now if she holds GUI/CMD/WIN, it will output a simple <code>`</code> character. ## Keycodes -|Key |Aliases |Description | -|---------|-----------|------------------------------------------------------------------| -|`KC_GESC`|`GRAVE_ESC`|Escape when pressed, <code>`</code> when Shift or GUI are held| +|Key |Aliases |Description | +|-----------------|---------|------------------------------------------------------------------| +|`QK_GRAVE_ESCAPE`|`QK_GESC`|Escape when pressed, <code>`</code> when Shift or GUI are held| ### Caveats diff --git a/docs/feature_haptic_feedback.md b/docs/feature_haptic_feedback.md index c8c74cb8f0..63ac4305ff 100644 --- a/docs/feature_haptic_feedback.md +++ b/docs/feature_haptic_feedback.md @@ -167,7 +167,7 @@ List of waveform sequences from the datasheet: ``` #define DRV_GREETING *sequence name or number* ``` -If haptic feedback is enabled, the keyboard will vibrate to a specific sqeuence during startup. That can be selected using the following define: +If haptic feedback is enabled, the keyboard will vibrate to a specific sequence during startup. That can be selected using the following define: ``` #define DRV_MODE_DEFAULT *sequence name or number* @@ -191,9 +191,6 @@ With the entry of `#define NO_HAPTIC_MOD` in config.h, the following keys will n * `TT()` layer tap toggle keys, when held to activate a layer. However when tapped `TAPPING_TOGGLE` times to permanently toggle the layer, on the last tap haptic feedback is still triggered. * `MT()` mod tap keys, when held to keep a usual modifier key pressed. However when tapped, and the key is quickly released, and sends a keycode, haptic feedback is still triggered. See also [Mod-Tap](mod_tap.md). -### NO_HAPTIC_FN -With the entry of `#define NO_HAPTIC_FN` in config.h, deprecated `fn_actions` type function keys will not trigger a feedback. - ### NO_HAPTIC_ALPHA With the entry of `#define NO_HAPTIC_ALPHA` in config.h, none of the alpha keys (A ... Z) will trigger a feedback. @@ -207,4 +204,4 @@ With the entry of `#define NO_HAPTIC_LOCKKEYS` in config.h, none of the followin With the entry of `#define NO_HAPTIC_NAV` in config.h, none of the following keys will trigger a feedback: Print Screen, Pause, Insert, Delete, Page Down, Page Up, Left Arrow, Up Arrow, Right Arrow, Down Arrow, End, Home. ### NO_HAPTIC_NUMERIC -With the entry of `#define NO_HAPTIC_NUMERIC` in config.h, none of the following keys between 0 and 9 (KC_1 ... KC_0) will trigger a feedback.
\ No newline at end of file +With the entry of `#define NO_HAPTIC_NUMERIC` in config.h, none of the following keys between 0 and 9 (KC_1 ... KC_0) will trigger a feedback. diff --git a/docs/feature_key_lock.md b/docs/feature_key_lock.md index 8e6e29f0e6..7681394229 100644 --- a/docs/feature_key_lock.md +++ b/docs/feature_key_lock.md @@ -19,4 +19,5 @@ First, enable Key Lock by setting `KEY_LOCK_ENABLE = yes` in your `rules.mk`. Th 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. -Switching layers will not cancel the Key Lock. +Switching layers will not cancel the Key Lock. The Key Lock can be cancelled by calling the `cancel_key_lock()` function. + diff --git a/docs/feature_led_matrix.md b/docs/feature_led_matrix.md index 37f38cc6ed..37c74843aa 100644 --- a/docs/feature_led_matrix.md +++ b/docs/feature_led_matrix.md @@ -68,6 +68,109 @@ const is31_led PROGMEM g_is31_leds[DRIVER_LED_TOTAL] = { Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](https://www.issi.com/WW/pdf/31FL3731.pdf) and the header file `drivers/led/issi/is31fl3731-simple.h`. The `driver` is the index of the driver you defined in your `config.h` (`0`, `1`, `2`, or `3` ). --- +### IS31FLCOMMON :id=is31flcommon + +There is basic support for addressable LED matrix lighting with a selection of I2C ISSI Lumissil LED controllers through a shared common driver. To enable it, add this to your `rules.mk`: + +```makefile +LED_MATRIX_ENABLE = yes +LED_MATRIX_DRIVER = <driver name> +``` + +Where `<driver name>` is the applicable LED driver chip as below + +| Driver Name | Data Sheet | Capability | +|-------------|------------|------------| +| `IS31FL3742A` | [datasheet](https://www.lumissil.com/assets/pdf/core/IS31FL3742A_DS.pdf) | 180 LED, 30x6 Matrix | +| `ISSIFL3743A` | [datasheet](https://www.lumissil.com/assets/pdf/core/IS31FL3743A_DS.pdf) | 198 LED, 18x11 Matrix | +| `IS31FL3745` | [datasheet](https://www.lumissil.com/assets/pdf/core/IS31FL3745_DS.pdf) | 144 LED, 18x8 Matrix | +| `IS31FL3746A` | [datasheet](https://www.lumissil.com/assets/pdf/core/IS31FL3746A_DS.pdf) | 72 LED, 18x4 Matrix | + +You can use between 1 and 4 IC's. Do not specify `DRIVER_ADDR_<N>` define for IC's if not present on your keyboard. The `DRIVER_ADDR_1` default assumes that all Address pins on the controller have been connected to GND. Drivers that have SYNC functionality have the default settings to disable if 1 driver. If more than 1 drivers then `DRIVER_ADDR_1` will be set to Master and the remaiing ones set to Slave. + +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 | +| `DRIVER_COUNT` | (Required) How many LED driver IC's are present | | +| `DRIVER_LED_TOTAL` | (Required) How many LED lights are present across all drivers | | +| `DRIVER_ADDR_1` | (Optional) Address for the first LED driver | | +| `DRIVER_ADDR_<N>` | (Required) Address for the additional LED drivers | | +| `ISSI_SSR_<N>` | (Optional) Configuration for the Spread Spectrum Register | | +| `ISSI_CONFIGURATION` | (Optional) Configuration for the Configuration Register | | +| `ISSI_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF | +| `ISSI_PULLDOWNUP` | (Optional) Configuration for the Pull Up & Pull Down Register | | +| `ISSI_TEMP` | (Optional) Configuration for the Tempature Register | | +| `ISSI_PWM_ENABLE` | (Optional) Configuration for the PWM Enable Register | | +| `ISSI_PWM_SET` | (Optional) Configuration for the PWM Setting Register | | +| `ISSI_SCAL_LED ` | (Optional) Configuration for the LEDs Scaling Registers | 0xFF | +| `ISSI_MANUAL_SCALING` | (Optional) If you wish to configure the Scaling Registers manually | | + + +Defaults + +| Variable | IS31FL3742A | IS31FL3743A | IS31FL3745 | IS31FL3746 | +|----------|-------------|-------------|------------|------------| +| `DRIVER_ADDR_1` | 0b0110000 | 0b0100000 | 0b0100000 | 0b1100000 | +| `ISSI_SSR_1` | 0x00 | 0x00 / 0x60 | 0x00 / 0xC0 | 0x00 | +| `ISSI_SSR_<2-4>` | 0x00 | 0x40 | 0x80 | 0x00 | +| `ISSI_CONFIGURATION` | 0x31 | 0x01 | 0x31 | 0x01 | +| `ISSI_PULLDOWNUP` | 0x55 | 0x33 | 0x33 | 0x33 | +| `ISSI_TEMP` | N/A | 0x00 | 0x00 | 0x00 | +| `ISSI_PWM_ENABLE` | N/A | N/A | N/A | 0x00 | +| `ISSI_PWM_SET` | 0x00 | N/A | N/A | 0x00 | + +Here is an example using 2 drivers. + +```c +#define DRIVER_ADDR_2 0b0100001 + +#define DRIVER_COUNT 2 +#define DRIVER_1_LED_TOTAL 66 +#define DRIVER_2_LED_TOTAL 42 +#define DRIVER_LED_TOTAL (DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL) +``` +!> Note the parentheses, this is so when `DRIVER_LED_TOTAL` 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 4 drivers are supported, but it would be trivial to support for more. Note that using a combination of different drivers is not supported. All drivers must be of the same model. + +Define these arrays listing all the LEDs in your `<keyboard>.c`: + +```c +const is31_led __flash g_is31_leds[DRIVER_LED_TOTAL] = { +/* Refer to IS31 manual for these locations + * driver + * | LED address + * | | */ + { 0, CS1_SW1 }, + { 0, CS2_SW1 }, + // ... +} +``` + +Where `CSx_SWx` is the location of the LED in the matrix defined by the datasheet. The `driver` is the index of the driver you defined in your `config.h` (`0`, `1`, `2`, or `3` for now). + +`ISSI_MANUAL_SCALING` is used to override the Scaling for individual LED's. By default they will be set as per `ISSI_SCAL_LED`. In `config.h` set how many LED's you want to manually set scaling for. +Eg `#define ISSI_MANUAL_SCALING 3` + +Then Define the array listing all the LEDs you want to override in your `<keyboard>.c`: + +```c +const is31_led __flash g_is31_scaling[ISSI_MANUAL_SCALING] = { + * LED Index + * | Scaling + * | | */ + {5, 120}, + {9, 120}, + .... +} +``` + +Where LED Index is the position of the LED in the `g_is31_leds` array. The `scaling` value between 0 and 255 to be written to the Scaling Register. + +--- ## Common Configuration :id=common-configuration diff --git a/docs/feature_mouse_keys.md b/docs/feature_mouse_keys.md index 30f563a95d..905da36e43 100644 --- a/docs/feature_mouse_keys.md +++ b/docs/feature_mouse_keys.md @@ -59,13 +59,13 @@ This is the default mode. You can adjust the cursor and scrolling acceleration u |Define |Default|Description | |----------------------------|-------|---------------------------------------------------------| -|`MOUSEKEY_DELAY` |300 |Delay between pressing a movement key and cursor movement| -|`MOUSEKEY_INTERVAL` |50 |Time between cursor movements in milliseconds | -|`MOUSEKEY_MOVE_DELTA` |5 |Step size | +|`MOUSEKEY_DELAY` |10 |Delay between pressing a movement key and cursor movement| +|`MOUSEKEY_INTERVAL` |20 |Time between cursor movements in milliseconds | +|`MOUSEKEY_MOVE_DELTA` |8 |Step size | |`MOUSEKEY_MAX_SPEED` |10 |Maximum cursor speed at which acceleration stops | -|`MOUSEKEY_TIME_TO_MAX` |20 |Time until maximum cursor speed is reached | -|`MOUSEKEY_WHEEL_DELAY` |300 |Delay between pressing a wheel key and wheel movement | -|`MOUSEKEY_WHEEL_INTERVAL` |100 |Time between wheel movements | +|`MOUSEKEY_TIME_TO_MAX` |30 |Time until maximum cursor speed is reached | +|`MOUSEKEY_WHEEL_DELAY` |10 |Delay between pressing a wheel key and wheel movement | +|`MOUSEKEY_WHEEL_INTERVAL` |80 |Time between wheel movements | |`MOUSEKEY_WHEEL_MAX_SPEED` |8 |Maximum number of scroll steps per scroll action | |`MOUSEKEY_WHEEL_TIME_TO_MAX`|40 |Time until maximum scroll speed is reached | @@ -85,9 +85,9 @@ This is an extension of the accelerated mode. The kinetic mode uses a quadratic |Define |Default |Description | |--------------------------------------|---------|---------------------------------------------------------------| |`MK_KINETIC_SPEED` |undefined|Enable kinetic mode | -|`MOUSEKEY_DELAY` |8 |Delay between pressing a movement key and cursor movement | -|`MOUSEKEY_INTERVAL` |8 |Time between cursor movements in milliseconds | -|`MOUSEKEY_MOVE_DELTA` |25 |Step size for accelerating from initial to base speed | +|`MOUSEKEY_DELAY` |5 |Delay between pressing a movement key and cursor movement | +|`MOUSEKEY_INTERVAL` |10 |Time between cursor movements in milliseconds | +|`MOUSEKEY_MOVE_DELTA` |5 |Step size for accelerating from initial to base speed | |`MOUSEKEY_INITIAL_SPEED` |100 |Initial speed of the cursor in pixel per second | |`MOUSEKEY_BASE_SPEED` |1000 |Maximum cursor speed at which acceleration stops | |`MOUSEKEY_DECELERATED_SPEED` |400 |Decelerated cursor speed | diff --git a/docs/feature_pointing_device.md b/docs/feature_pointing_device.md index fb6936620c..4b39599f8a 100644 --- a/docs/feature_pointing_device.md +++ b/docs/feature_pointing_device.md @@ -2,7 +2,7 @@ Pointing Device is a generic name for a feature intended to be generic: moving the system pointer around. There are certainly other options for it - like mousekeys - but this aims to be easily modifiable and hardware driven. You can implement custom keys to control functionality, or you can gather information from other peripherals and insert it directly here - let QMK handle the processing for you. -To enable Poin |