summaryrefslogtreecommitdiffstats
path: root/docs/feature_rgb_matrix.md
diff options
context:
space:
mode:
authorJames Young <18669334+noroadsleft@users.noreply.github.com>2020-03-15 20:29:11 -0700
committerGitHub <noreply@github.com>2020-03-15 20:29:11 -0700
commitb272c035ba7fa8555a88c922b3e94c3f3817c4ff (patch)
treea5c9a1f6e4a1d9c02b72a12e33b2f9e69b5bf85b /docs/feature_rgb_matrix.md
parent5f1f370463d818a5283a17001ad832073efc45a4 (diff)
[Docs] Random Fixes (#8340)
* fix CLI section links in the Summary * fix heading in Pointing Device doc * fix headings in PS/2 Mouse Support doc * add explicit section ids to I2C Master Driver doc * reformat GPIO Controls table Much like the I2C Master Driver doc, I found this a bit less than ideal to read. (The table was actually wider than the space available for it.) Reformatted so each GPIO function is an H3 heading, followed by a paragraph and a table of each architecture's old-style function. * migrate changes from I2C Master Driver doc to Japanese translation * add explicit anchors to I2C Master Driver docs * fix code block language markers The language markers are case-sensitive; using the wrong case means the syntax highlighting doesn't work. Good: ```c Bad: ```C * restore Japanese I2C Master Driver doc to current master Can't update the internal tracking references accurately until the changes to the English doc are committed to master. * add explicit anchors to edited files * change ChibiOS/ARM to ARM/ChibiOS Because ARM/ATSAM is also a thing that exists. * fix code block language markers again Used the wrong markers in a few spots. Also these are apparently always supposed to be lowercase. * add section anchors to cli.md * restore table formatting on GPIO Control doc * remove changes to _summary.md
Diffstat (limited to 'docs/feature_rgb_matrix.md')
-rw-r--r--docs/feature_rgb_matrix.md56
1 files changed, 28 insertions, 28 deletions
diff --git a/docs/feature_rgb_matrix.md b/docs/feature_rgb_matrix.md
index 23082ef2a9..7bc2193472 100644
--- a/docs/feature_rgb_matrix.md
+++ b/docs/feature_rgb_matrix.md
@@ -1,22 +1,22 @@
-# RGB Matrix Lighting
+# RGB Matrix Lighting :id=rgb-matrix-lighting
This feature allows you to use RGB LED matrices driven by external drivers. It hooks into the RGBLIGHT system so you can use the same keycodes as RGBLIGHT to control it.
If you want to use single color LED's you should use the [LED Matrix Subsystem](feature_led_matrix.md) instead.
-## Driver configuration
+## Driver configuration :id=driver-configuration
---
-### IS31FL3731
+### IS31FL3731 :id=is31fl3731
There is basic support for addressable RGB matrix lighting with the I2C IS31FL3731 RGB controller. To enable it, add this to your `rules.mk`:
-```C
+```makefile
RGB_MATRIX_ENABLE = IS31FL3731
```
Configure the hardware via your `config.h`:
-```C
+```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:
@@ -39,7 +39,7 @@ Currently only 2 drivers are supported, but it would be trivial to support all 4
Define these arrays listing all the LEDs in your `<keyboard>.c`:
-```C
+```c
const is31_led g_is31_leds[DRIVER_LED_TOTAL] = {
/* Refer to IS31 manual for these locations
* driver
@@ -55,19 +55,19 @@ const is31_led g_is31_leds[DRIVER_LED_TOTAL] = {
Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](http://www.issi.com/WW/pdf/31FL3731.pdf) and the header file `drivers/issi/is31fl3731.h`. The `driver` is the index of the driver you defined in your `config.h` (`0` or `1` right now).
---
-### IS31FL3733/IS31FL3737
+### IS31FL3733/IS31FL3737 :id=is31fl3733is31fl3737
!> For the IS31FL3737, replace all instances of `IS31FL3733` below with `IS31FL3737`.
There is basic support for addressable RGB matrix lighting with the I2C IS31FL3733 RGB controller. To enable it, add this to your `rules.mk`:
-```C
+```makefile
RGB_MATRIX_ENABLE = IS31FL3733
```
Configure the hardware via your `config.h`:
-```C
+```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:
@@ -90,7 +90,7 @@ Currently only a single drivers is supported, but it would be trivial to support
Define these arrays listing all the LEDs in your `<keyboard>.c`:
-```C
+```c
const is31_led g_is31_leds[DRIVER_LED_TOTAL] = {
/* Refer to IS31 manual for these locations
* driver
@@ -107,17 +107,17 @@ Where `X_Y` is the location of the LED in the matrix defined by [the datasheet](
---
-### WS2812
+### WS2812 :id=ws2812
There is basic support for addressable RGB matrix lighting with a WS2811/WS2812{a,b,c} addressable LED strand. To enable it, add this to your `rules.mk`:
-```C
+```makefile
RGB_MATRIX_ENABLE = WS2812
```
Configure the hardware via your `config.h`:
-```C
+```c
// The pin connected to the data pin of the LEDs
#define RGB_DI_PIN D7
// The number of LEDs connected
@@ -128,7 +128,7 @@ Configure the hardware via your `config.h`:
From this point forward the configuration is the same for all the drivers. The `led_config_t` struct provides a key electrical matrix to led index lookup table, what the physical position of each LED is on the board, and what type of key or usage the LED if the LED represents. Here is a brief example:
-```C
+```c
const led_config_t g_led_config = { {
// Key Matrix to LED Index
{ 5, NO_LED, NO_LED, 0 },
@@ -146,7 +146,7 @@ const led_config_t g_led_config = { {
The first part, `// Key Matrix to LED Index`, tells the system what key this LED represents by using the key's electrical matrix row & col. The second part, `// LED Index to Physical Position` represents the LED's physical `{ x, y }` position on the keyboard. The default expected range of values for `{ x, y }` is the inclusive range `{ 0..224, 0..64 }`. This default expected range is due to effects that calculate the center of the keyboard for their animations. The easiest way to calculate these positions is imagine your keyboard is a grid, and the top left of the keyboard represents `{ x, y }` coordinate `{ 0, 0 }` and the bottom right of your keyboard represents `{ 224, 64 }`. Using this as a basis, you can use the following formula to calculate the physical position:
-```C
+```c
x = 224 / (NUMBER_OF_COLS - 1) * COL_POSITION
y = 64 / (NUMBER_OF_ROWS - 1) * ROW_POSITION
```
@@ -157,7 +157,7 @@ As mentioned earlier, the center of the keyboard by default is expected to be `{
`// LED Index to Flag` is a bitmask, whether or not a certain LEDs is of a certain type. It is recommended that LEDs are set to only 1 type.
-## Flags
+## Flags :id=flags
|Define |Description |
|------------------------------------|-------------------------------------------|
@@ -169,7 +169,7 @@ As mentioned earlier, the center of the keyboard by default is expected to be `{
|`#define LED_FLAG_UNDERGLOW 0x02` |If the LED is for underglow. |
|`#define LED_FLAG_KEYLIGHT 0x04` |If the LED is for key backlight. |
-## Keycodes
+## Keycodes :id=keycodes
All RGB keycodes are currently shared with the RGBLIGHT system:
@@ -189,11 +189,11 @@ All RGB keycodes are currently shared with the RGBLIGHT system:
* `RGB_MODE_*` keycodes will generally work, but are not currently mapped to the correct effects for the RGB Matrix system
-## RGB Matrix Effects
+## RGB Matrix Effects :id=rgb-matrix-effects
All effects have been configured to support current configuration values (Hue, Saturation, Value, & Speed) unless otherwise noted below. These are the effects that are currently available:
-```C
+```c
enum rgb_matrix_effects {
RGB_MATRIX_NONE = 0,
RGB_MATRIX_SOLID_COLOR = 1, // Static single hue, no speed support
@@ -285,7 +285,7 @@ You can disable a single effect by defining `DISABLE_[EFFECT_NAME]` in your `con
|`#define DISABLE_RGB_MATRIX_SOLID_MULTISPLASH` |Disables `RGB_MATRIX_SOLID_MULTISPLASH` |
-## Custom RGB Matrix Effects
+## Custom RGB Matrix Effects :id=custom-rgb-matrix-effects
By setting `RGB_MATRIX_CUSTOM_USER` (and/or `RGB_MATRIX_CUSTOM_KB`) in `rules.mk`, new effects can be defined directly from userspace, without having to edit any QMK core files.
@@ -294,7 +294,7 @@ To declare new effects, create a new `rgb_matrix_user/kb.inc` that looks somethi
`rgb_matrix_user.inc` should go in the root of the keymap directory.
`rgb_matrix_kb.inc` should go in the root of the keyboard directory.
-```C
+```c
// !!! DO NOT ADD #pragma once !!! //
// Step 1.
@@ -341,7 +341,7 @@ static bool my_cool_effect2(effect_params_t* params) {
For inspiration and examples, check out the built-in effects under `quantum/rgb_matrix_animation/`
-## Colors
+## Colors :id=colors
These are shorthands to popular colors. The `RGB` ones can be passed to the `setrgb` functions, while the `HSV` ones to the `sethsv` functions.
@@ -369,9 +369,9 @@ These are shorthands to popular colors. The `RGB` ones can be passed to the `set
These are defined in [`rgblight_list.h`](https://github.com/qmk/qmk_firmware/blob/master/quantum/rgblight_list.h). Feel free to add to this list!
-## Additional `config.h` Options
+## Additional `config.h` Options :id=additional-configh-options
-```C
+```c
#define RGB_MATRIX_KEYPRESSES // reacts to keypresses
#define RGB_MATRIX_KEYRELEASES // reacts to keyreleases (instead of keypresses)
#define RGB_DISABLE_AFTER_TIMEOUT 0 // number of ticks to wait until disabling effects
@@ -386,21 +386,21 @@ These are defined in [`rgblight_list.h`](https://github.com/qmk/qmk_firmware/blo
#define RGB_MATRIX_STARTUP_SPD 127 // Sets the default animation speed, if none has been set
```
-## EEPROM storage
+## EEPROM storage :id=eeprom-storage
The EEPROM for it is currently shared with the RGBLIGHT system (it's generally assumed only one RGB would be used at a time), but could be configured to use its own 32bit address with:
-```C
+```c
#define EECONFIG_RGB_MATRIX (uint32_t *)28
```
Where `28` is an unused index from `eeconfig.h`.
-## Suspended state
+## Suspended state :id=suspended-state
To use the suspend feature, add this to your `<keyboard>.c`:
-```C
+```c
void suspend_power_down_kb(void)
{
rgb_matrix_set_suspend_state(true);