Merge remote-tracking branch 'upstream/develop' into xap
This commit is contained in:
Nick Brassel
commit
c9ec8a1309
1525 changed files with 26368 additions and 6063 deletions
|
|
@ -62,7 +62,7 @@ This shows us that the job has made it through the queue and is currently runnin
|
|||
|
||||
Once your compile job has finished you'll check the `result` key. The value of this key is a hash containing several key bits of information:
|
||||
|
||||
* `firmware_binary_url`: A list of URLs for the the flashable firmware
|
||||
* `firmware_keymap_url`: A list of URLs for the the `keymap.c`
|
||||
* `firmware_binary_url`: A list of URLs for the flashable firmware
|
||||
* `firmware_keymap_url`: A list of URLs for the `keymap.c`
|
||||
* `firmware_source_url`: A list of URLs for the full firmware source code
|
||||
* `output`: The stdout and stderr for this compile job. Errors will be found here.
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ or in keymap directory
|
|||
```
|
||||
$ cd ~/qmk_firmware/keyboards/gh60/satan/keymaps/colemak
|
||||
$ qmk compile
|
||||
Ψ Compiling keymap with make make gh60/satan:colemak
|
||||
Ψ Compiling keymap with make gh60/satan:colemak
|
||||
...
|
||||
```
|
||||
|
||||
|
|
@ -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`
|
||||
|
|
|
|||
|
|
@ -61,6 +61,8 @@ This is a C header file that is one of the first things included, and will persi
|
|||
* pins unused by the keyboard for reference
|
||||
* `#define MATRIX_HAS_GHOST`
|
||||
* define is matrix has ghost (unlikely)
|
||||
* `#define MATRIX_UNSELECT_DRIVE_HIGH`
|
||||
* On un-select of matrix pins, rather than setting pins to input-high, sets them to output-high.
|
||||
* `#define DIODE_DIRECTION COL2ROW`
|
||||
* COL2ROW or ROW2COL - how your matrix is configured. COL2ROW means the black mark on your diode is facing to the rows, and between the switch and the rows.
|
||||
* `#define DIRECT_PINS { { F1, F0, B0, C7 }, { F4, F5, F6, F7 } }`
|
||||
|
|
|
|||
|
|
@ -408,7 +408,7 @@ The `val` is the value of the data that you want to write to EEPROM. And the `e
|
|||
|
||||
### Deferred Execution :id=deferred-execution
|
||||
|
||||
QMK has the ability to execute a callback after a specified period of time, rather than having to manually manage timers.
|
||||
QMK has the ability to execute a callback after a specified period of time, rather than having to manually manage timers. To enable this functionality, set `DEFERRED_EXEC_ENABLE = yes` in rules.mk.
|
||||
|
||||
#### Deferred executor callbacks
|
||||
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ Whenever QMK generates a complete `info.json` it extracts information from `conf
|
|||
|
||||
If you are not sure how to edit this file or are not comfortable with Python [open an issue](https://github.com/qmk/qmk_firmware/issues/new?assignees=&labels=cli%2C+python&template=other_issues.md&title=) or [join #cli on Discord](https://discord.gg/heQPAgy) and someone can help you with this part.
|
||||
|
||||
### Add code to generate it
|
||||
### Add code to generate it :id=add-code-to-generate-it
|
||||
|
||||
The final piece of the puzzle is providing your new option to the build system. This is done by generating two files:
|
||||
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ bool encoder_update_user(uint8_t index, bool clockwise) {
|
|||
}
|
||||
```
|
||||
|
||||
!> If you return `true`, this will allow the keyboard level code to run, as well. Returning `false` will override the keyboard level code. Depending on how the keyboard level function is set up.
|
||||
!> If you return `true`, it will allow the keyboard level code to run as well. Returning `false` will override the keyboard level code, depending on how the keyboard function is set up.
|
||||
|
||||
Layer conditions can also be used with the callback function like the following:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# LED Indicators
|
||||
|
||||
?> This feature requires additional configuration to work on both halves of a split keyboard see [Data sync options](feature_split_keyboard.md#data-sync-options)
|
||||
?> LED indicators on split keyboards will require state information synced to the slave half (e.g. `#define SPLIT_LED_STATE_ENABLE`). See [data sync options](feature_split_keyboard.md#data-sync-options) for more details.
|
||||
|
||||
QMK provides methods to read 5 of the LEDs defined in the HID spec:
|
||||
|
||||
|
|
|
|||
|
|
@ -67,6 +67,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
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ You can define up to 32 macros in a `keymap.json` file, as used by [Configurator
|
|||
|
||||
### Selecting Your Host Keyboard Layout
|
||||
|
||||
If you type in a language other than English, or use a non-QWERTY layout like Colemak, Dvorak, or Workman, you may have set your computer's input language to match this layout. This presents a challenge when creating macros- you may need to type different keys to get the same letters! To address this you can add the `host_language` key to your keymap.json, like so:
|
||||
If you type in a language other than English, or use a non-QWERTY layout like Colemak, Dvorak, or Workman, you may have set your computer's input language to match this layout. This presents a challenge when creating macros - you may need to type different keys to get the same letters! To address this you can add the `host_language` key to your `keymap.json`, like so:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -75,7 +75,7 @@ The current list of available languages is:
|
|||
|
||||
### Macro Basics
|
||||
|
||||
Each macro is an array consisting of strings and objects (dictionaries.) Strings are typed to your computer while objects allow you to control how your macro is typed out.
|
||||
Each macro is an array consisting of strings and objects (dictionaries). Strings are typed to your computer while objects allow you to control how your macro is typed out.
|
||||
|
||||
#### Object Format
|
||||
|
||||
|
|
|
|||
|
|
@ -164,7 +164,7 @@ small and detailed movements of the cursor.
|
|||
* **KC_ACL2:** This acceleration sets your cursor to the maximum (computer defined) speed. This is
|
||||
useful for moving the cursor large distances without much accuracy.
|
||||
|
||||
To use constant speed mode, you must at least define `MK_COMBINED` in your keymap’s `config.h` file:
|
||||
To use combined speed mode, you must at least define `MK_COMBINED` in your keymap’s `config.h` file:
|
||||
|
||||
```c
|
||||
#define MK_COMBINED
|
||||
|
|
|
|||
|
|
@ -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 Pointing Device, uncomment the following line in your rules.mk:
|
||||
To enable Pointing Device, add the following line in your rules.mk and specify one of the driver options below.
|
||||
|
||||
```make
|
||||
POINTING_DEVICE_ENABLE = yes
|
||||
|
|
@ -181,7 +181,13 @@ The CPI range is 50-16000, in increments of 50. Defaults to 2000 CPI.
|
|||
|
||||
### Custom Driver
|
||||
|
||||
If you have a sensor type that isn't supported here, you can manually implement it, by adding these functions (with the correct implementation for your device):
|
||||
If you have a sensor type that isn't supported above, a custom option is available by adding the following to your `rules.mk`
|
||||
|
||||
```make
|
||||
POINTING_DEVICE_DRIVER = custom
|
||||
```
|
||||
|
||||
Using the custom driver will require implementing the following functions:
|
||||
|
||||
```c
|
||||
void pointing_device_driver_init(void) {}
|
||||
|
|
|
|||
|
|
@ -232,6 +232,115 @@ const is31_led PROGMEM g_is31_leds[DRIVER_LED_TOTAL] = {
|
|||
|
||||
Where `X_Y` is the location of the LED in the matrix defined by [the datasheet](https://www.issi.com/WW/pdf/31FL3737.pdf) and the header file `drivers/led/issi/is31fl3737.h`. The `driver` is the index of the driver you defined in your `config.h` (Only `0`, `1` for now).
|
||||
|
||||
---
|
||||
### IS31FLCOMMON :id=is31flcommon
|
||||
|
||||
There is basic support for addressable RGB matrix lighting with a selection of I2C ISSI Lumissil RGB controllers through a shared common driver. To enable it, add this to your `rules.mk`:
|
||||
|
||||
```makefile
|
||||
RGB_MATRIX_ENABLE = yes
|
||||
RGB_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) | 60 RGB, 30x6 Matrix |
|
||||
| `ISSIFL3743A` | [datasheet](https://www.lumissil.com/assets/pdf/core/IS31FL3743A_DS.pdf) | 66 RGB, 18x11 Matrix |
|
||||
| `IS31FL3745` | [datasheet](https://www.lumissil.com/assets/pdf/core/IS31FL3745_DS.pdf) | 48 RGB, 18x8 Matrix |
|
||||
| `IS31FL3746A` | [datasheet](https://www.lumissil.com/assets/pdf/core/IS31FL3746A_DS.pdf) | 24 RGB, 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 remaining 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 RGB driver IC's are present | |
|
||||
| `DRIVER_LED_TOTAL` | (Required) How many RGB lights are present across all drivers | |
|
||||
| `DRIVER_ADDR_1` | (Optional) Address for the first RGB driver | |
|
||||
| `DRIVER_ADDR_<N>` | (Required) Address for the additional RGB 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_RED` | (Optional) Configuration for the RED LEDs in Scaling Registers | 0xFF |
|
||||
| `ISSI_SCAL_BLUE` | (Optional) Configuration for the BLUE LEDs in Scaling Registers | 0xFF |
|
||||
| `ISSI_SCAL_GREEN` | (Optional) Configuration for the GREEN LEDs in 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
|
||||
* | R location
|
||||
* | | G location
|
||||
* | | | B location
|
||||
* | | | | */
|
||||
{0, CS1_SW1, CS2_SW1, CS3_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_<colour>`. 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
|
||||
* | R scaling
|
||||
* | | G scaling
|
||||
* | | | B scaling
|
||||
* | | | | */
|
||||
{5, 120, 155, 167},
|
||||
{9, 120, 155, 167},
|
||||
....
|
||||
}
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
### WS2812 :id=ws2812
|
||||
|
|
@ -418,6 +527,8 @@ All RGB keycodes are currently shared with the RGBLIGHT system:
|
|||
`RGB_MODE_PLAIN`, `RGB_MODE_BREATHE`, `RGB_MODE_RAINBOW`, and `RGB_MODE_SWIRL` are the only ones that are mapped properly. The rest don't have a direct equivalent, and are not mapped.
|
||||
|
||||
?> `RGB_*` keycodes cannot be used with functions like `tap_code16(RGB_HUD)` as they're not USB HID keycodes. If you wish to replicate similar behaviour in custom code within your firmware (e.g. inside `encoder_update_user()` or `process_record_user()`), the equivalent [RGB functions](#functions-idfunctions) should be used instead.
|
||||
|
||||
|
||||
!> By default, if you have both the [RGB Light](feature_rgblight.md) and the RGB Matrix feature enabled, these keycodes will work for both features, at the same time. You can disable the keycode functionality by defining the `*_DISABLE_KEYCODES` option for the specific feature.
|
||||
|
||||
## RGB Matrix Effects :id=rgb-matrix-effects
|
||||
|
|
@ -455,6 +566,7 @@ enum rgb_matrix_effects {
|
|||
RGB_MATRIX_HUE_PENDULUM, // Hue shifts up a slight ammount in a wave to the right, then back to the left
|
||||
RGB_MATRIX_HUE_WAVE, // Hue shifts up a slight ammount and then back down in a wave to the right
|
||||
RGB_MATRIX_PIXEL_FRACTAL, // Single hue fractal filled keys pulsing horizontally out to edges
|
||||
RGB_MATRIX_PIXEL_FLOW, // Pulsing RGB flow along LED wiring with random hues
|
||||
RGB_MATRIX_PIXEL_RAIN, // Randomly light keys with random hues
|
||||
#if define(RGB_MATRIX_FRAMEBUFFER_EFFECTS)
|
||||
RGB_MATRIX_TYPING_HEATMAP, // How hot is your WPM!
|
||||
|
|
@ -510,6 +622,7 @@ You can enable a single effect by defining `ENABLE_[EFFECT_NAME]` in your `confi
|
|||
|`#define ENABLE_RGB_MATRIX_HUE_PENDULUM` |Enables `RGB_MATRIX_HUE_PENDULUM` |
|
||||
|`#define ENABLE_RGB_MATRIX_HUE_WAVE` |Enables `RGB_MATRIX_HUE_WAVE ` |
|
||||
|`#define ENABLE_RGB_MATRIX_PIXEL_FRACTAL` |Enables `RGB_MATRIX_PIXEL_FRACTAL` |
|
||||
|`#define ENABLE_RGB_MATRIX_PIXEL_FLOW` |Enables `RGB_MATRIX_PIXEL_FLOW` |
|
||||
|`#define ENABLE_RGB_MATRIX_PIXEL_RAIN` |Enables `RGB_MATRIX_PIXEL_RAIN` |
|
||||
|
||||
?> These modes don't require any additional defines.
|
||||
|
|
@ -555,9 +668,7 @@ In order to change the delay of temperature decrease define
|
|||
|
||||
## Custom RGB Matrix Effects :id=custom-rgb-matrix-effects
|
||||
|
||||
By setting `RGB_MATRIX_CUSTOM_USER = yes` in `rules.mk`, new effects can be defined directly from your keymap or userspace, without having to edit any QMK core files.
|
||||
|
||||
To declare new effects, create a `rgb_matrix_user.inc` file in the user keymap directory or userspace folder.
|
||||
By setting `RGB_MATRIX_CUSTOM_USER = yes` in `rules.mk`, new effects can be defined directly from your keymap or userspace, without having to edit any QMK core files. To declare new effects, create a `rgb_matrix_user.inc` file in the user keymap directory or userspace folder.
|
||||
|
||||
?> Hardware maintainers who want to limit custom effects to a specific keyboard can create a `rgb_matrix_kb.inc` file in the root of the keyboard directory, and add `RGB_MATRIX_CUSTOM_KB = yes` to the keyboard level `rules.mk`.
|
||||
|
||||
|
|
@ -707,6 +818,7 @@ Where `28` is an unused index from `eeconfig.h`.
|
|||
|`rgb_matrix_decrease_speed_noeeprom()` |Decrease the speed of the animations (not written to EEPROM) |
|
||||
|`rgb_matrix_set_speed(speed)` |Set the speed of the animations to the given value where `speed` is between 0 and 255 |
|
||||
|`rgb_matrix_set_speed_noeeprom(speed)` |Set the speed of the animations to the given value where `speed` is between 0 and 255 (not written to EEPROM) |
|
||||
|`rgb_matrix_reload_from_eeprom()` |Reload the effect configuration (enabled, mode and color) from EEPROM |
|
||||
|
||||
### Change Color :id=change-color
|
||||
|Function |Description |
|
||||
|
|
@ -810,6 +922,8 @@ void rgb_matrix_indicators_advanced_user(uint8_t led_min, uint8_t led_max) {
|
|||
}
|
||||
```
|
||||
|
||||
?> Split keyboards will require layer state data syncing with `#define SPLIT_LAYER_STATE_ENABLE`. See [Data Sync Options](feature_split_keyboard?id=data-sync-options) for more details.
|
||||
|
||||
#### Examples :id=indicator-examples
|
||||
|
||||
This example sets the modifiers to be a specific color based on the layer state. You can use a switch case here, instead, if you would like. This uses HSV and then converts to RGB, because this allows the brightness to be limited (important when using the WS2812 driver).
|
||||
|
|
|
|||
|
|
@ -76,9 +76,10 @@ Changing the **Value** sets the overall brightness.<br>
|
|||
|`RGB_MODE_RGBTEST` |`RGB_M_T` |Red, Green, Blue test animation mode |
|
||||
|`RGB_MODE_TWINKLE` |`RGB_M_TW`|Twinkle animation mode |
|
||||
|
||||
!> By default, if you have both the RGB Light and the [RGB Matrix](feature_rgb_matrix.md) feature enabled, these keycodes will work for both features, at the same time. You can disable the keycode functionality by defining the `*_DISABLE_KEYCODES` option for the specific feature.
|
||||
?> `RGB_*` keycodes cannot be used with functions like `tap_code16(RGB_HUI)` as they're not USB HID keycodes. If you wish to replicate similar behaviour in custom code within your firmware (e.g. inside `encoder_update_user()` or `process_record_user()`), the equivalent [RGB functions](#functions) should be used instead.
|
||||
|
||||
?> `RGB_*` keycodes cannot be used with functions like `tap_code16(RGB_HUI)` as they're not USB HID keycodes. If you wish to replicate similar behaviour in custom code within your firmware (e.g. inside `encoder_update_user()` or `process_record_user()`), the equivalent [RGB functions](#functions-idfunctions) should be used instead.
|
||||
|
||||
!> By default, if you have both the RGB Light and the [RGB Matrix](feature_rgb_matrix.md) feature enabled, these keycodes will work for both features, at the same time. You can disable the keycode functionality by defining the `*_DISABLE_KEYCODES` option for the specific feature.
|
||||
|
||||
## Configuration
|
||||
|
||||
|
|
@ -203,7 +204,7 @@ const uint8_t RGBLED_GRADIENT_RANGES[] PROGMEM = {255, 170, 127, 85, 64};
|
|||
|
||||
## Lighting Layers
|
||||
|
||||
?> **Note:** Lighting Layers is an RGB Light feature, it will not work for RGB Matrix. See [RGB Matrix Indicators](feature_rgb_matrix.md?indicators) for details on how to do so.
|
||||
?> **Note:** Lighting Layers is an RGB Light feature, it will not work for RGB Matrix. See [RGB Matrix Indicators](feature_rgb_matrix.md#indicators) for details on how to do so.
|
||||
|
||||
By including `#define RGBLIGHT_LAYERS` in your `config.h` file you can enable lighting layers. These make
|
||||
it easy to use your underglow LEDs as status indicators to show which keyboard layer is currently active, or the state of caps lock, all without disrupting any animations. [Here's a video](https://youtu.be/uLGE1epbmdY) showing an example of what you can do.
|
||||
|
|
|
|||
|
|
@ -243,7 +243,7 @@ Now, at the bottom of your `keymap.c` file, you'll need to add the following:
|
|||
*
|
||||
* How to figure out tap dance state: interrupted and pressed.
|
||||
*
|
||||
* Interrupted: If the state of a dance dance is "interrupted", that means that another key has been hit
|
||||
* Interrupted: If the state of a dance is "interrupted", that means that another key has been hit
|
||||
* under the tapping term. This is typically indicitive that you are trying to "tap" the key.
|
||||
*
|
||||
* Pressed: Whether or not the key is still being pressed. If this value is true, that means the tapping term
|
||||
|
|
|
|||
24
docs/flash_driver.md
Normal file
24
docs/flash_driver.md
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
# FLASH Driver Configuration :id=flash-driver-configuration
|
||||
|
||||
The FLASH driver can be swapped out depending on the needs of the keyboard, or whether extra hardware is present.
|
||||
|
||||
Driver | Description
|
||||
-----------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
`FLASH_DRIVER = spi` | Supports writing to almost all NOR Flash chips. See the driver section below.
|
||||
|
||||
|
||||
## SPI FLASH Driver Configuration :id=spi-flash-driver-configuration
|
||||
|
||||
Currently QMK supports almost all NOR Flash chips over SPI. As such, requires a working spi_master driver configuration. You can override the driver configuration via your config.h:
|
||||
|
||||
`config.h` override | Description | Default Value
|
||||
-----------------------------------------------|--------------------------------------------------------------------------------------|-----------------
|
||||
`#define EXTERNAL_FLASH_SPI_SLAVE_SELECT_PIN` | SPI Slave select pin in order to inform that the FLASH is currently being addressed | _none_
|
||||
`#define EXTERNAL_FLASH_SPI_CLOCK_DIVISOR` | Clock divisor used to divide the peripheral clock to derive the SPI frequency | `8`
|
||||
`#define EXTERNAL_FLASH_PAGE_SIZE` | The Page size of the FLASH in bytes, as specified in the datasheet | `256`
|
||||
`#define EXTERNAL_FLASH_SECTOR_SIZE` | The sector size of the FLASH in bytes, as specified in the datasheet | `(4 * 1024)`
|
||||
`#define EXTERNAL_FLASH_BLOCK_SIZE` | The block size of the FLASH in bytes, as specified in the datasheet | `(64 * 1024)`
|
||||
`#define EXTERNAL_FLASH_SIZE` | The total size of the FLASH in bytes, as specified in the datasheet | `(512 * 1024)`
|
||||
`#define EXTERNAL_FLASH_ADDRESS_SIZE` | The Flash address size in bytes, as specified in datasheet | `3`
|
||||
|
||||
!> All the above default configurations are based on MX25L4006E NOR Flash.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Keyboards with AVR Processors
|
||||
|
||||
This page describes the support for for AVR processors in QMK. AVR processors include the atmega32u4, atmega32u2, at90usb1286, and other processors from Atmel Corporation. AVR processors are 8-bit MCUs that are designed to be easy to work with. The most common AVR processors in keyboards have on-board USB and plenty of GPIO for supporting large keyboard matrices. They are the most popular MCU for use in keyboards today.
|
||||
This page describes the support for AVR processors in QMK. AVR processors include the atmega32u4, atmega32u2, at90usb1286, and other processors from Atmel Corporation. AVR processors are 8-bit MCUs that are designed to be easy to work with. The most common AVR processors in keyboards have on-board USB and plenty of GPIO for supporting large keyboard matrices. They are the most popular MCU for use in keyboards today.
|
||||
|
||||
If you have not yet you should read the [Keyboard Guidelines](hardware_keyboard_guidelines.md) to get a sense of how keyboards fit into QMK.
|
||||
|
||||
|
|
|
|||
|
|
@ -87,6 +87,7 @@ The `config.h` files can also be placed in sub-folders, and the order in which t
|
|||
* `keyboards/top_folder/sub_1/sub_2/config.h`
|
||||
* `keyboards/top_folder/sub_1/sub_2/sub_3/config.h`
|
||||
* `keyboards/top_folder/sub_1/sub_2/sub_3/sub_4/config.h`
|
||||
* [`.build/objs_<keyboard>/src/info_config.h`](data_driven_config.md#add-code-to-generate-it) see [Data Driven Configuration](data_driven_config.md)
|
||||
* `users/a_user_folder/config.h`
|
||||
* `keyboards/top_folder/keymaps/a_keymap/config.h`
|
||||
* `keyboards/top_folder/sub_1/sub_2/sub_3/sub_4/post_config.h`
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ $ qmk compile -km 66_iso
|
|||
```
|
||||
$ cd ~/qmk_firmware/keyboards/gh60/satan/keymaps/colemak
|
||||
$ qmk compile
|
||||
Ψ Compiling keymap with make make gh60/satan:colemak
|
||||
Ψ Compiling keymap with make gh60/satan:colemak
|
||||
...
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Unfortunately, these keycodes cannot be used in Mod-Taps or Layer-Taps, since an
|
|||
|
||||
Additionally, you may run into issues when using Remote Desktop Connection on Windows. Because these codes send shift very fast, Remote Desktop may miss the codes.
|
||||
|
||||
To fix this, open Remote Desktop Connection, click on "Show Options", open the the "Local Resources" tab. In the keyboard section, change the drop down to "On this Computer". This will fix the issue, and allow the characters to work correctly.
|
||||
To fix this, open Remote Desktop Connection, click on "Show Options", open the "Local Resources" tab. In the keyboard section, change the drop down to "On this Computer". This will fix the issue, and allow the characters to work correctly.
|
||||
|
||||
## Keycodes
|
||||
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ Currently, the `kc` argument of `MT()` is limited to the [Basic Keycode set](key
|
|||
Expanding this would be complicated, at best. Moving to a 32-bit keycode would solve a lot of this, but would double the amount of space that the keymap matrix uses. And it could potentially cause issues, too. If you need to apply modifiers to your tapped keycode, [Tap Dance](feature_tap_dance.md#example-5-using-tap-dance-for-advanced-mod-tap-and-layer-tap-keys) can be used to accomplish this.
|
||||
|
||||
You may also run into issues when using Remote Desktop Connection on Windows. Because these keycodes send key events faster than a human, Remote Desktop could miss them.
|
||||
To fix this, open Remote Desktop Connection, click on "Show Options", open the the "Local Resources" tab, and in the keyboard section, change the drop down to "On this Computer". This will fix the issue, and allow the characters to work correctly.
|
||||
To fix this, open Remote Desktop Connection, click on "Show Options", open the "Local Resources" tab, and in the keyboard section, change the drop down to "On this Computer". This will fix the issue, and allow the characters to work correctly.
|
||||
It can also be mitigated by increasing [`TAP_CODE_DELAY`](config_options.md#behaviors-that-can-be-configured).
|
||||
|
||||
## Intercepting Mod-Taps
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ Once both plugins are installed, restart Eclipse as prompted.
|
|||
|
||||
## Build Your Keyboard
|
||||
|
||||
We will now change the default make target of the the project from `all` to the
|
||||
We will now change the default make target of the project from `all` to the
|
||||
specific keyboard and keymap combination we are working on,
|
||||
e.g. `kinesis/kint36:stapelberg`. This way, project-wide actions like cleaning
|
||||
and building the project will complete quickly, instead of taking a long time or
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ The purpose of this page is to document how to set up VS Code for developing QMK
|
|||
This guide covers how to configure everything needed on Windows and Ubuntu 18.04
|
||||
|
||||
# Set up VS Code
|
||||
Before starting, you will want to make sure that you have all of the build tools set up, and QMK Firmware cloned. Head to the the [Newbs Getting Started Guide](newbs_getting_started.md) to get things set up, if you haven't already.
|
||||
Before starting, you will want to make sure that you have all of the build tools set up, and QMK Firmware cloned. Head to the [Newbs Getting Started Guide](newbs_getting_started.md) to get things set up, if you haven't already.
|
||||
|
||||
## Windows
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ If there are any inconsistencies with these recommendations, you're best off [cr
|
|||
|
||||
- PR should be submitted using a non-`master` branch on the source repository
|
||||
- this does not mean you target a different branch for your PR, rather that you're not working out of your own master branch
|
||||
- if submitter _does_ use their own `master` branch, they'll be given a link to the ["how to git"](https://docs.qmk.fm/#/newbs_git_using_your_master_branch) page after merging -- (end of this document will contain the contents of the message)
|
||||
- if submitter _does_ use their own `master` branch, they'll be given a link to the ["how to git"](newbs_git_using_your_master_branch.md) page after merging -- (end of this document will contain the contents of the message)
|
||||
- newly-added directories and filenames must be lowercase
|
||||
- this rule may be relaxed if upstream sources originally had uppercase characters (e.g. LUFA, ChibiOS, or imported files from other repositories etc.)
|
||||
- if there is valid justification (i.e. consistency with existing core files etc.) this can be relaxed
|
||||
|
|
@ -76,9 +76,9 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
|
|||
- `<keyboard>.c`
|
||||
- empty `xxxx_xxxx_kb()` or other weak-defined default implemented functions removed
|
||||
- commented-out functions removed too
|
||||
- `matrix_init_board()` etc. migrated to `keyboard_pre_init_kb()`, see: [keyboard_pre_init*](https://docs.qmk.fm/#/custom_quantum_functions?id=keyboard_pre_init_-function-documentation)
|
||||
- prefer `CUSTOM_MATRIX = lite` if custom matrix used, allows for standard debounce, see [custom matrix 'lite'](https://docs.qmk.fm/#/custom_matrix?id=lite)
|
||||
- prefer LED indicator [Configuration Options](https://docs.qmk.fm/#/feature_led_indicators?id=configuration-options) to custom `led_update_*()` implementations where possible
|
||||
- `matrix_init_board()` etc. migrated to `keyboard_pre_init_kb()`, see: [keyboard_pre_init*](custom_quantum_functions.md?id=keyboard_pre_init_-function-documentation)
|
||||
- prefer `CUSTOM_MATRIX = lite` if custom matrix used, allows for standard debounce, see [custom matrix 'lite'](custom_matrix.md?id=lite)
|
||||
- prefer LED indicator [Configuration Options](feature_led_indicators.md?id=configuration-options) to custom `led_update_*()` implementations where possible
|
||||
- `<keyboard>.h`
|
||||
- `#include "quantum.h"` appears at the top
|
||||
- `LAYOUT` macros should use standard definitions if applicable
|
||||
|
|
@ -111,13 +111,13 @@ Also, specific to ChibiOS:
|
|||
- example: For an STM32L082KZ, given the similarity to an STM32L073RZ, you can use `BOARD = ST_NUCLEO64_L073RZ` in rules.mk
|
||||
- QMK is migrating to not having custom board definitions if at all possible, due to the ongoing maintenance burden when upgrading ChibiOS
|
||||
- New board definitions must not be embedded in a keyboard PR
|
||||
- See _Core PRs_ below for the procedure for adding a new board to QMK
|
||||
- See [Core PRs](#core-pr) below for the procedure for adding a new board to QMK
|
||||
- if a board definition is unavoidable, `board.c` must have a standard `__early_init()` (as per normal ChibiOS board defs) and an empty `boardInit()`:
|
||||
- see Arm/ChibiOS [early initialization](https://docs.qmk.fm/#/platformdev_chibios_earlyinit?id=board-init)
|
||||
- see Arm/ChibiOS [early initialization](platformdev_chibios_earlyinit.md?id=board-init)
|
||||
- `__early_init()` should be replaced by either `early_hardware_init_pre()` or `early_hardware_init_post()` as appropriate
|
||||
- `boardInit()` should be migrated to `board_init()`
|
||||
|
||||
## Core PRs
|
||||
## Core PRs :id=core-pr
|
||||
|
||||
- must now target `develop` branch, which will subsequently be merged back to `master` on the breaking changes timeline
|
||||
- any new boards adding support for new hardware now requires a corresponding test board under `keyboards/handwired/onekey`
|
||||
|
|
|
|||
|
|
@ -147,6 +147,7 @@ For RGB Matrix, these need to be explicitly enabled as well. To disable any that
|
|||
#undef ENABLE_RGB_MATRIX_HUE_PENDULUM
|
||||
#undef ENABLE_RGB_MATRIX_HUE_WAVE
|
||||
#undef ENABLE_RGB_MATRIX_PIXEL_FRACTAL
|
||||
#undef ENABLE_RGB_MATRIX_PIXEL_FLOW
|
||||
#undef ENABLE_RGB_MATRIX_PIXEL_RAIN
|
||||
|
||||
#undef ENABLE_RGB_MATRIX_TYPING_HEATMAP
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ $ qmk compile -km 66_iso
|
|||
```
|
||||
$ cd ~/qmk_firmware/keyboards/gh60/satan/keymaps/colemak
|
||||
$ qmk compile
|
||||
Ψ Compiling keymap with make make gh60/satan:colemak
|
||||
Ψ Compiling keymap with make gh60/satan:colemak
|
||||
...
|
||||
```
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue