* Add GKB-M16 Macro Pad
Add GKB-M16 (gkb_m16) Macro Pad under gkeyboard
* Update keyboards/gkeyboard/gkb_m16/config.h
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/gkeyboard/gkb_m16/keymaps/via/keymap.c
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/gkeyboard/gkb_m16/info.json
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/gkeyboard/gkb_m16/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Initial commit on new clean branch. Testing out functionality of oled and encoder for default features.
* Cleaned up the initial push and removed the fancy keymap until the extra features and functionality can be tested and made more user friendly.
* Cleaned up the readme some more, compiled and tested both default and via keymaps, and did another round of checks to prepare for starting the PR.
* Cleaning up the keymap to meet expected formatting in a couple places and also adding in the TAP_CODE_DELAY after newly encoutnered encoder issues and inconsistencies.
* Apply suggestions from code review
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/mechwild/mercutio/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Fixing json syntax.
* Update keyboards/mechwild/mercutio/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Quark PCB for Planck/Preonic
Quark provides alternate bottom row layouts for both the OLKB Planck and Preonic
* Rename rules.mk.txt to rules.mk
* added Tapping Toggle
removed tapping toggle from keymap level
* Update info.json
took out } as requested
* update config.h
added GPL2+ license and #pragma once
* update info.json again
cleaned up syntax
* Apply suggestions from code review
Co-authored-by: Drashna Jaelre <drashna@live.com>
* update config.h
added GPL2+ License
* Update info.json - and again
fixed it - oops
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Add target 'build-for-compare' to `build_keyboard.mk`
The `build-for-compare` target provides an easy way to check the md5 checksum of the generated binary.
You can easily see if there is any change in the generated binaries between the two versions, as in the example below.
```
$ git checkout 0.11.0
M build_keyboard.mk
M tmk_core/rules.mk
Note: checking out '0.11.0'.
HEAD is now at c66df1664 2020 November 28 Breaking Changes Update (#11053)
$ make helix:all:build-for-compare | grep ^MD5
MD5 (.build/helix_rev2_default.hex) = 5c3606562c944bb4d18832e601b45d4a
MD5 (.build/helix_rev2_edvorakjp.hex) = 9e43d13d389d518ba7e99cd7337e28d6
MD5 (.build/helix_rev2_five_rows.hex) = 8bcb61c2fd5d237c2997f2fa007d4934
MD5 (.build/helix_rev2_five_rows_jis.hex) = b97cd818d52f73ca2d4e78c86d90a791
MD5 (.build/helix_rev2_froggy.hex) = c492172364188f4e2918b10bf0f3a0a6
MD5 (.build/helix_rev2_froggy_106.hex) = b0861fd735a8f81881a8c02730641a2b
MD5 (.build/helix_rev2_led_test.hex) = 5c97d982a5da5cfb3dacb28a8934b81d
MD5 (.build/helix_rev2_xulkal.hex) = 01f603dc46bcf9094d7e106831d8f5b1
MD5 (.build/helix_rev2_yshrsmz.hex) = 5a008bca2d0c5790a151c02834c529ba
$ git checkout 0.11.1
M build_keyboard.mk
M tmk_core/rules.mk
Previous HEAD position was c66df1664 2020 November 28 Breaking Changes Update (#11053)
HEAD is now at cc08e3082 nix-shell: add milc dependency (#11086)
$ make helix:all:build-for-compare | grep ^MD5
MD5 (.build/helix_rev2_default.hex) = 5c3606562c944bb4d18832e601b45d4a
MD5 (.build/helix_rev2_edvorakjp.hex) = 9e43d13d389d518ba7e99cd7337e28d6
MD5 (.build/helix_rev2_five_rows.hex) = 8bcb61c2fd5d237c2997f2fa007d4934
MD5 (.build/helix_rev2_five_rows_jis.hex) = b97cd818d52f73ca2d4e78c86d90a791
MD5 (.build/helix_rev2_froggy.hex) = c492172364188f4e2918b10bf0f3a0a6
MD5 (.build/helix_rev2_froggy_106.hex) = b0861fd735a8f81881a8c02730641a2b
MD5 (.build/helix_rev2_led_test.hex) = 5c97d982a5da5cfb3dacb28a8934b81d
MD5 (.build/helix_rev2_xulkal.hex) = d848383adfd7463b138c6da179cf1436
MD5 (.build/helix_rev2_yshrsmz.hex) = 5a008bca2d0c5790a151c02834c529ba
```
* make builds reproducable by default
* update build_keyboard.mk: remove 'build-for-compare' target
* GNU make (3.81) on macOS 10.14(Mojave) does not have the 'undefine' directive.
* Adopted fauxpark's suggestion.
* Update tmk_core/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* update tmk_core/rules.mk
* fix tmk_core/rules.mk
Co-authored-by: Zach White <skullydazed@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Make parameters from info.json available to the build system
* move all clueboard settings to info.json
* code formatting
* make flake8 happy
* make flake8 happy
* make qmk lint happy
* Add support for specifying led indicators in json
* move led indicators to the clueboard info.json
* Apply suggestions from code review
Co-authored-by: Erovia <Erovia@users.noreply.github.com>
* add missing docstring
Co-authored-by: Erovia <Erovia@users.noreply.github.com>
* Update ADB impelmentation in tmk_core to recent version.
Pcked from tmk_keyboard repository revision: 48d696443857512d45f9a7329e0dd0a76345860f
* Restore convenient ADB functions used in QMK port.
* Do cformat.
* Rewrite APA102 support
The APA102 source was broken by commit 16a15c1cfcbfd0feb2c2cf1383676747e2f97d73 as it did not include the
quantum header. This commit addresses that, as well as other issues with
transferring bytes over the SPI interface, i.e. it was not setting the
clock pin back to low after sending a bit.
The deviation when sending the end frame is kept, but updated to the
latest from the referenced project.
Finally, these changes expose the global LED brightness parameter
of the APA102. Brightness values are configurable through
`APA102_DEFAULT_BRIGHTNESS` and `APA102_MAX_BRIGHTNESS`.
* Fix typo in led brightness extern
* Move driver out of AVR directory and add delay for ARM
* Experimental APA102 support on AVR and ARM
Co-authored-by: Alde Rojas <hello@alde.io>
* Refactor apa102_send_byte() calls to a loop
* Implement io_wait function for ARM
* Move APA102 drivers to own directory, fix copyright notice
* Add APA102 keymap to handwired/onekey
* Simplify RGBLIGHT_ENABLE/DRIVER option handling
Co-authored-by: Mikkel Jeppesen <2756925+Duckle29@users.noreply.github.com>
* Add modifier state to the split transport
This adds modifier state to the i2c and serial transport for split
keyboards. The purpose of this is to allow e.g. displaying modifier
state on the slave side of a split keyboard on an oled. This adds one
byte to the data transferred between halves.
This also fixes a missing ifdef guard for BLACKLIGHT_ENABLE.
Break modifiers into real/weak/oneshot
Fix incorrect slave serial mod setting
Fix typo in serial weal mod setter
Fix build errors for the I2C code that I introduced
Code cleanup and formatting per project preferences
Correctly get oneshot mods
Fix missing braces
Remove unneeded ifdef guard
Make the added state transport optional
Add documentation for the new define to enable this feature
Fix stray grave mark
* Fix error introduced in conflict resolution
* Split dmac_desc declaration and definition
According to the official documentation[1] gcc 10 is more strict about
correct extern usage.
I've had to move the definition of dmac_desc and dmac_desc_wb from
i2c_master.h to the corresponding .c file. This could be an issue if
anyone includes the i2c_master.h file without liking with the object
file.
[1]: https://gcc.gnu.org/gcc-10/porting_to.html
* Remove the keymap_config definition from keymaps
The keymap_config def was conflicting with the one found in
tmk_core/common/magic.c. Declaring it extern in magic.c breaks a bunch
of keyboard that rely on that declaration (like the ergodox). Instead
I've removed the one found in the keymap.c of the massdrop alt.
The same change will have to be made to other keyboards.
* Disable almost all ChibiOS subsystems.
* Modify ChibiOS config updater script to fixup mcuconf include, use develop as base instead of master.
* Add default early-init bootloader to F042/F072.
* Back to 100k freq.
- Set all other ChibiOS defaults to 'off', when not targeting Proton-C
- Modified all existing F303 boards to point at the QMK_PROTON_C to ensure repeatable binary output
- Modified version.h generation so that SKIP_VERSION=yes generates the same output
This command allows you to convert from raw KLE data to QMK Configurator JSON. It accepts either an absolute file path, or a file name in the current directory. By default it will not overwrite `info.json` if it is already present. Use the `-f` or `--force` flag to overwrite.
This command allows you to convert [Keyboard-Layout-Editor.com](http://keyboard-layout-editor.com) layouts into `info.json` layouts. It will also create a `keymap.json` file for your layout. This saves a lot of time when setting up a new keyboard.
To use this command your KLE will need to follow a specific format. See [KLE To info.json](kle2json_guide.md) for more details.
@ -42,6 +42,7 @@ In your keymap you can use the following keycodes to map key presses to mouse ac
Mouse keys supports three different modes to move the cursor:
* **Accelerated (default):** Holding movement keys accelerates the cursor until it reaches its maximum speed.
* **Kinetic:** Holding movement keys accelerates the cursor with its speed following a quadratic curve until it reaches its maximum speed.
* **Constant:** Holding movement keys moves the cursor at constant speeds.
* **Combined:** Holding movement keys accelerates the cursor until it reaches its maximum speed, but holding acceleration and movement keys simultaneously moves the cursor at constant speeds.
@ -56,7 +57,8 @@ This is the default mode. You can adjust the cursor and scrolling acceleration u
|`MOUSEKEY_DELAY` |300 |Delay between pressing a movement key and cursor movement|
|`MOUSEKEY_INTERVAL` |50 |Time between cursor movements |
|`MOUSEKEY_INTERVAL` |50 |Time between cursor movements in milliseconds |
|`MOUSEKEY_MOVE_DELTA` |5 |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 |
@ -73,6 +75,30 @@ Tips:
Cursor acceleration uses the same algorithm as the X Window System MouseKeysAccel feature. You can read more about it [on Wikipedia](https://en.wikipedia.org/wiki/Mouse_keys).
### Kinetic Mode
This is an extension of the accelerated mode. The kinetic mode uses a quadratic curve on the cursor speed which allows precise movements at the beginning and allows to cover large distances by increasing cursor speed quickly thereafter. You can adjust the cursor and scrolling acceleration using the following settings in your keymap’s `config.h` file:
* The smoothness of the cursor movement depends on the `MOUSEKEY_INTERVAL` setting. The shorter the interval is set the smoother the movement will be. Setting the value too low makes the cursor unresponsive. Lower settings are possible if the micro processor is fast enough. For example: At an interval of `8` milliseconds, `125` movements per second will be initiated. With a base speed of `1000` each movement will move the cursor by `8` pixels.
* Mouse wheel movements are implemented differently from cursor movements. While it's okay for the cursor to move multiple pixels at once for the mouse wheel this would lead to jerky movements. Instead, the mouse wheel operates at step size `1`. Setting mouse wheel speed is done by adjusting the number of wheel movements per second.
### Constant mode
In this mode you can define multiple different speeds for both the cursor and the mouse wheel. There is no acceleration. `KC_ACL0`, `KC_ACL1` and `KC_ACL2` change the cursor and scroll speed to their respective setting.
@ -129,6 +129,28 @@ Configure the hardware via your `config.h`:
---
### APA102 :id=apa102
There is basic support for APA102 based addressable LED strands. To enable it, add this to your `rules.mk`:
```makefile
RGB_MATRIX_ENABLE = yes
RGB_MATRIX_DRIVER = APA102
```
Configure the hardware via your `config.h`:
```c
// The pin connected to the data pin of the LEDs
#define RGB_DI_PIN D7
// The pin connected to the clock pin of the LEDs
#define RGB_CI_PIN D6
// The number of LEDs connected
#define DRIVER_LED_TOTAL 70
```
---
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:
@ -10,6 +10,7 @@ Currently QMK supports the following addressable LEDs (however, the white LED in
* WS2811, WS2812, WS2812B, WS2812C, etc.
* SK6812, SK6812MINI, SK6805
* APA102
These LEDs are called "addressable" because instead of using a wire per color, each LED contains a small microchip that understands a special protocol sent over a single wire. The chip passes on the remaining data to the next LED, allowing them to be chained together. In this way, you can easily control the color of the individual LEDs.
@ -21,11 +22,19 @@ On keyboards with onboard RGB LEDs, it is usually enabled by default. If it is n
RGBLIGHT_ENABLE = yes
```
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`. If your keyboard has onboard RGB LEDs, and you are simply creating a keymap, you usually won't need to modify these.
For APA102 LEDs, add the following to your `rules.mk`:
```make
RGBLIGHT_ENABLE = yes
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.
@ -78,7 +78,7 @@ Established materials and techniques include:
| Short lengths of wire | [u/xicolinguada's ortho build](https://www.reddit.com/r/MechanicalKeyboards/comments/c39k4f/my_first_hand_wired_keyboard_its_not_perfect_but/) | Easier to strip the wire | More difficult to place | 
| Magnet/Enamelled wire | [Brett Kosinski's handwired alpha](http://blog.b-ark.ca/Blog-2019-01-27) and [fknraiden's custom board](https://geekhack.org/index.php?topic=74223.0) | Can be directly soldered onto (insulation burns off with heat) | Appearance? | 
| Bending the legs of the diodes for the rows | [Matt3o's Brownfox](https://deskthority.net/viewtopic.php?f=7&t=6050) | Fewer solder joints required | Uninsulated | 
| Using ridid wiring (e.g. brass tube) | [u/d_stilgar's invisible hardline](https://www.reddit.com/r/MechanicalKeyboards/comments/8aw5j2/invisible_hardline_keyboard_progress_update_april/) and [u/jonasfasler's first attempt](https://www.reddit.com/r/MechanicalKeyboards/comments/de1jyv/my_first_attempt_at_handwiring_a_keyboard/) | Very pretty | More difficult. No physical insulation | 
| Using rigid wiring (e.g. brass tube) | [u/d_stilgar's invisible hardline](https://www.reddit.com/r/MechanicalKeyboards/comments/8aw5j2/invisible_hardline_keyboard_progress_update_april/) and [u/jonasfasler's first attempt](https://www.reddit.com/r/MechanicalKeyboards/comments/de1jyv/my_first_attempt_at_handwiring_a_keyboard/) | Very pretty | More difficult. No physical insulation | 
| Bare wire with insulation added after (e.g. kapton tape) | [Matt3o's 65% on his website](https://matt3o.com/hand-wiring-a-custom-keyboard/) | Easier (no wire stripping required) | Not as attractive | 
| Copper tape | [ManuForm Dactyl](https://github.com/tshort/dactyl-keyboard) | Very easy | Only really works when your plate/case aligns with the bottom of your switches | 
@ -121,7 +121,7 @@ Letting the diode rest, grab your solder, and touch both it and the soldering ir
The smoke that the rosin releases is harmful, so be careful not to breath it or get it in your eyes/face.
After soldering things in place, it may be helpful to blow on the joint to push the smoke away from your face, and cool the solder quicker. You should see the solder develop a matte (not shiny) surface as it solidifies. Keep in mind that it will still be very hot afterwards, and will take a couple minutes to be cool to touch. Blow on it will accelerate this process.
After soldering things in place, it may be helpful to blow on the joint to push the smoke away from your face, and cool the solder quicker. You should see the solder develop a matte (not shiny) surface as it solidifies. Keep in mind that it will still be very hot afterwards, and will take a couple minutes to be cool to touch. Blowing on it will accelerate this process.
When the first diode is complete, the next one will need to be soldered to both the keyswitch, and the previous diode at the new elbow. That will look something like this:
This page describes how to create a [Keyboard Layout Editor](http://keyboard-layout-editor.com) layout that works with `qmk kle2json`. You will also be able to use the same KLE layout to create VIA support for your keyboard.
## Overview
QMK uses `info.json` to store metadata about the keyboard including the matrix pins, row and column configuration, and keyboard layout. You can encode some of this data into a KLE layout and then convert that to `info.json`, which saves you time and headaches creating files from scratch.
Our reference layout is here: <http://www.keyboard-layout-editor.com/#/gists/70aaa4bed76d0b2f67fd165641239552>
Keep that open in a separate window so that you can refer to it while reading this document.
## Layout Structure
The first thing you should notice is that the main layout for the keyboard is in the middle. This is the default layout. Around the sides you'll find layout options. These are groups of keys that can replace specific keys in the default layout. More on that later.
## Anatomy of a Key
Every key in KLE has 12 labels- top left, top center, top right, center left, center, center right, bottom left, bottom center, bottom right, front left, front center, front right. We do not use all 12 labels, but we do some of them.
The labels we use are below:
| | | |
|-|-|-|
| **Matrix** | (unused) | (unused) |
| **Keycode** | (unused) | (unused) |
| (unused) | (unused) | **Option Group** |
| **Option Name** | (unused) | (unused) |
### Matrix
This is the location of the key in the keyboard matrix. It should be two whole numbers separated by a comma representing row and column. For example, the top left location of the keyboard is usually `0,0`, to the right of that key is `0,1`, below that key is `1,0`, and so on.
### Keycode
This is the default keycode for layer 0. You should supply this now even if you won't use the generated keymap because QMK will make greater use of it in the future.
### Option Group
This identifies what Layout Options (if any) this key is part of. If this value is empty the key is not part of any Layout Options.
The value is two whole numbers separated by a comma. The first number is the Layout Option Group Number, which identifies the specific Layout Option this key is associated with. The second number is the specific Layout Option Choice this key is associated with.
### Option Name
This identifies the name for each Option Group Choice. This will be used in the future to automatically build layouts from each option. All keys with the same Option Group identifier should have the same Option Name.
## Running qmk kle2json
Once you have built your KLE layout you are ready to convert it to `info.json`. Start by clicking `Sign In with GitHub` on Keyboard Layout Editor. Once you have signed in you can click `Save` to save your KLE. Once it's saved grab the URL from the bar, it should end end in `/#/gists/<long_number>`.
To use the reference layout as an example, I could update the keyboard `clueboard/60` from that KLE using this command:
It will fetch the KLE, generate a new `LAYOUT_60_ansi`, and either add a new layout or change the existing layout to match.
## Adding more layouts
At the current time QMK only supports the base layout. Layout Options are allowed for VIA compatibility purposes and will be implemented in QMK at a later date. For now we recommend you create a KLE for each layout you want to support in QMK and call `qmk kle2json` once per layout to set up the info.json.
@ -19,8 +19,20 @@ The `info.json` file is a JSON formatted dictionary with the following keys avai
* Width of the board in Key Units
* `height`
* Height of the board in Key Units
* `debounce`
* How many milliseconds (ms) to wait for debounce to happen. (Default: 5)
* `diode_direction`
* The direction diodes face. See [`DIRECT_PINS` in the hardware configuration](https://docs.qmk.fm/#/config_options?id=hardware-options) for more details.
* `layout_aliases`
* A dictionary containing layout aliases. The key is the alias and the value is a layout in `layouts` it maps to.
* `layouts`
* Physical Layout representations. See the next section for more detail.
* Physical Layout representations. See the [Layout Format](#layout_format) section for more detail.
* `matrix_pins`
* Configure the pins corresponding to columns and rows, or direct pins. See [Matrix Pins](#matrix_pins) for more detail.
* `rgblight`
* Configure the [RGB Lighting feature](feature_rgblight.md). See the [RGB Lighting](#rgb_lighting) section for more detail.
* `usb`
* Configure USB VID, PID, and other parameters. See [USB](#USB) for more detail.
### Layout Format
@ -49,25 +61,128 @@ All key positions and rotations are specified in relation to the top-left corner
* The width of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
* `h`
* The height of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
* `r`
* How many degrees clockwise to rotate the key.
* `rx`
* The absolute position of the point to rotate the key around in the horizontal axis. Default: `x`
* `ry`
* The absolute position of the point to rotate the key around in the vertical axis. Default: `y`
* `ks`
* Key Shape: define a polygon by providing a list of points, in Key Units.
* **Important**: These are relative to the top-left of the key, not absolute.
* Example ISO Enter: `[ [0,0], [1.5,0], [1.5,2], [0.25,2], [0.25,1], [0,1], [0,0] ]`
* `label`
* What to name this position in the matrix.
* This should usually be the same name as what is silkscreened on the PCB at this location.
* This should usually correspond to the keycode for the first layer of the default keymap.
* `matrix`
* A 2 item list describing the row and column location for this key.
## How is the Metadata Exposed?
### Matrix Pins
This metadata is primarily used in two ways:
Currently QMK supports connecting switches either directly to GPIO pins or via a switch matrix. At this time you can not combine these, they are mutually exclusive.
* To allow web-based configurators to dynamically generate UI
* To support the new `make keyboard:keymap:qmk` target, which bundles this metadata up with the firmware to allow QMK Toolbox to be smarter.
#### Switch Matrix
Configurator authors can see the [QMK Compiler](https://docs.api.qmk.fm/using-the-api) docs for more information on using the JSON API.
Most keyboards use a switch matrix to connect keyswitches to the MCU. You can define your pin columns and rows to configure your switch matrix. When defining switch matrices you should also define your `diode_direction`.
Example:
```json
{
"diode_direction": "COL2ROW",
"matrix_pins": {
"cols": ["F4", "E6", "B1", "D2"],
"rows": ["B0", "D3", "D5", "D4", "D6"]
}
}
```
#### Direct Pins
Direct pins are when you connect one side of the switch to GND and the other side to a GPIO pin on your MCU. No diode is required, but there is a 1:1 mapping between switches and pins.
When specifying direct pins you need to arrange them in nested arrays. The outer array consists of rows, while the inner array is a text string corresponding to a pin. You can use `null` to indicate an empty spot in the matrix.
Example:
```json
{
"matrix_pins": {
"direct": [
["A10", "A9"],
["A0", "B8"],
[null, "B11"],
["B9", "A8"],
["A7", "B1"],
[null, "B2"]
]
}
```
### RGB Lighting
This section controls the legacy WS2812 support in QMK. This should not be confused with the RGB Matrix feature, which can be used to control both WS2812 and ISSI RGB LEDs.
The following items can be set. Not every value is required.
* `led_count`
* The number of LEDs in your strip
* `pin`
* The GPIO pin that your LED strip is connected to
* `animations`
* A dictionary that lists enabled and disabled animations. See [RGB Light Animations](#rgb_light_animations) below.
* `sleep`
* Set to `true` to enable lighting during host sleep
* `split`
* Set to `true` to enable synchronization functionality between split halves
* `split_count`
* For split keyboards, the number of LEDs on each side
* `max_brightness`
* (0-255) What the maxmimum brightness (value) level is
* `hue_steps`
* How many steps of adjustment to have for hue
* `saturation_steps`
* How many steps of adjustment to have for saturation
* `brightness_steps`
* How many steps of adjustment to have for brightness (value)
Example:
```json
{
"rgblight": {
"led_count": 4,
"pin": "F6",
"hue_steps": 10,
"saturation_steps": 17,
"brightness_steps": 17,
"animations": {
"all": true
}
}
}
```
#### RGB Light Animations
The following animations can be enabled:
| Key | Description |
|-----|-------------|
| `all` | Enable all additional animation modes. |
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
