| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Fixes #1199.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
More specifically, we save them and then place the `macro_end` pointer
before them so they are essentially ignored and the other macro may
freely overwrite them.
|
| |
|
|
|
|
| |
We need to check whether we just passed the after-the-end point of the
other macro. Instead we were checking whether we are going to reach it
now.
|
| |
|
|
| |
Apparently sometimes the backlight was toggled only once and it was left on.
|
| |
|
|
|
|
|
|
| |
Right after the user initiates the macro recording, they usually need
to release some keys used to access the DYN_REC_START layers. It makes
sense to ignore them.
Note: The keys used to access the DYN_REC_STOP key are *not* ignored.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dynamic macro functionality is modified to check for `DYN_REC_STOP`, so
that macro recording can be stopped with a designated key combination
(e.g. `qs` or anything) instead of mandating the use of a `_DYN` layer.
`_DYN` layer stopping can still be done by passing `DYN_REC_STOP` within
`process_record_user()`:
bool process_record_user(uint16_t keycode, keyrecord_t *record) {
uint16_t macro_kc = (keycode == MO(_DYN) ? DYN_REC_STOP : keycode);
if (!process_record_dynamic_macro(macro_kc, record)) {
return false;
}
return true;
}
|
| |
|
|
|
|
|
|
|
|
| |
* Clarify the license for files we have signoff on
* Update against the currently signed off files
* Remove unused and not clearly licensed headers
* Replace an #endif I accidentally removed while resolving merge conflicts
|
| |
|
|
|
| |
There have been reports of it leaving not enough free memory preventing
the keyboard from working properly.
|
| |
|
