Merge remote-tracking branch 'origin/develop' into xap
This commit is contained in:
		
						commit
						3c20f00238
					
				
					 41 changed files with 421 additions and 101 deletions
				
			
		| 
						 | 
				
			
			@ -657,18 +657,19 @@ You can enable a single effect by defining `ENABLE_[EFFECT_NAME]` in your `confi
 | 
			
		|||
 | 
			
		||||
### RGB Matrix Effect Typing Heatmap :id=rgb-matrix-effect-typing-heatmap
 | 
			
		||||
 | 
			
		||||
This effect will color the RGB matrix according to a heatmap of recently pressed
 | 
			
		||||
keys. Whenever a key is pressed its "temperature" increases as well as that of
 | 
			
		||||
its neighboring keys. The temperature of each key is then decreased
 | 
			
		||||
automatically every 25 milliseconds by default.
 | 
			
		||||
This effect will color the RGB matrix according to a heatmap of recently pressed keys. Whenever a key is pressed its "temperature" increases as well as that of its neighboring keys. The temperature of each key is then decreased automatically every 25 milliseconds by default.
 | 
			
		||||
 | 
			
		||||
In order to change the delay of temperature decrease define
 | 
			
		||||
`RGB_MATRIX_TYPING_HEATMAP_DECREASE_DELAY_MS`:
 | 
			
		||||
In order to change the delay of temperature decrease define `RGB_MATRIX_TYPING_HEATMAP_DECREASE_DELAY_MS`:
 | 
			
		||||
 | 
			
		||||
```c
 | 
			
		||||
#define RGB_MATRIX_TYPING_HEATMAP_DECREASE_DELAY_MS 50
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
Heatmap effect may not light up the correct adjacent LEDs for certain key matrix layout such as split keyboards. The following define will limit the effect to pressed keys only:
 | 
			
		||||
```c
 | 
			
		||||
#define RGB_MATRIX_TYPING_HEATMAP_SLIM
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
## 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.
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -326,6 +326,19 @@ void post_process_record_user(uint16_t keycode, keyrecord_t *record) {
 | 
			
		|||
```
 | 
			
		||||
would turn the layer 0 (or 1) on and off again three times when `DEBUG` is pressed.
 | 
			
		||||
 | 
			
		||||
Blinking accumulates layers so if multiple layers are set blinking at the same time they will all blink for the duration and repeat times of the last layer to be blinked.
 | 
			
		||||
To stop these other layers from blinking use `rgblight_unblink_layer` or `rgblight_unblink_all_but_layer`:
 | 
			
		||||
 | 
			
		||||
```c
 | 
			
		||||
rgblight_blink_layer(1, 500);
 | 
			
		||||
rgblight_unblink_all_but_layer(1);
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
```c
 | 
			
		||||
rgblight_unblink_layer(3);
 | 
			
		||||
rgblight_blink_layer(2, 500);
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
!> Lighting layers on split keyboards will require layer state synced to the slave half (e.g. `#define SPLIT_LAYER_STATE_ENABLE`). See [data sync options](feature_split_keyboard.md#data-sync-options) for more details.
 | 
			
		||||
 | 
			
		||||
### Overriding RGB Lighting on/off status
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -112,7 +112,7 @@ uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record) {
 | 
			
		|||
}
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
The reason being that `TAPPING_TERM` is a macro that expands to a constant integer and thus cannot be changed at runtime whereas `g_tapping_term` is a variable whose value can be changed at runtime. If you want, you can temporarily enable `DYNAMIC_TAPPING_TERM_ENABLE` to find a suitable tapping term value and then disable that feature and revert back to using the classic syntax for per-key tapping term settings.
 | 
			
		||||
The reason being that `TAPPING_TERM` is a macro that expands to a constant integer and thus cannot be changed at runtime whereas `g_tapping_term` is a variable whose value can be changed at runtime. If you want, you can temporarily enable `DYNAMIC_TAPPING_TERM_ENABLE` to find a suitable tapping term value and then disable that feature and revert back to using the classic syntax for per-key tapping term settings. In case you need to access the tapping term from elsewhere in your code, you can use the `GET_TAPPING_TERM(keycode, record)` macro. This macro will expand to whatever is the appropriate access pattern given the current configuration.
 | 
			
		||||
 | 
			
		||||
## Tap-Or-Hold Decision Modes
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue