2017-03-29 04:20:36 +06:00
|
|
|
/* Copyright 2016 Jack Humbert
|
|
|
|
*
|
|
|
|
* This program is free software: you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation, either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
2016-12-10 04:49:11 +06:00
|
|
|
#include "print.h"
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
#include "process_combo.h"
|
2016-12-10 04:49:11 +06:00
|
|
|
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
__attribute__((weak)) combo_t key_combos[COMBO_COUNT] = {
|
2016-12-10 20:11:59 +06:00
|
|
|
|
|
|
|
};
|
|
|
|
|
2019-08-31 00:19:03 +06:00
|
|
|
__attribute__((weak)) void process_combo_event(uint8_t combo_index, bool pressed) {}
|
2016-12-17 01:50:28 +06:00
|
|
|
|
2019-08-31 00:19:03 +06:00
|
|
|
static uint16_t timer = 0;
|
|
|
|
static uint8_t current_combo_index = 0;
|
|
|
|
static bool drop_buffer = false;
|
|
|
|
static bool is_active = false;
|
|
|
|
static bool b_combo_enable = true; // defaults to enabled
|
2016-12-17 01:50:28 +06:00
|
|
|
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
static uint8_t buffer_size = 0;
|
2016-12-17 01:50:28 +06:00
|
|
|
#ifdef COMBO_ALLOW_ACTION_KEYS
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
static keyrecord_t key_buffer[MAX_COMBO_LENGTH];
|
2016-12-17 01:50:28 +06:00
|
|
|
#else
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
static uint16_t key_buffer[MAX_COMBO_LENGTH];
|
2016-12-10 20:11:59 +06:00
|
|
|
#endif
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
|
|
|
|
static inline void send_combo(uint16_t action, bool pressed) {
|
2019-08-31 00:19:03 +06:00
|
|
|
if (action) {
|
|
|
|
if (pressed) {
|
|
|
|
register_code16(action);
|
|
|
|
} else {
|
|
|
|
unregister_code16(action);
|
|
|
|
}
|
2016-12-10 20:11:59 +06:00
|
|
|
} else {
|
2019-08-31 00:19:03 +06:00
|
|
|
process_combo_event(current_combo_index, pressed);
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
}
|
|
|
|
}
|
2016-12-10 04:49:11 +06:00
|
|
|
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
static inline void dump_key_buffer(bool emit) {
|
2019-08-31 00:19:03 +06:00
|
|
|
if (buffer_size == 0) {
|
|
|
|
return;
|
|
|
|
}
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
|
2019-08-31 00:19:03 +06:00
|
|
|
if (emit) {
|
|
|
|
for (uint8_t i = 0; i < buffer_size; i++) {
|
2016-12-17 01:50:28 +06:00
|
|
|
#ifdef COMBO_ALLOW_ACTION_KEYS
|
2019-08-31 00:19:03 +06:00
|
|
|
const action_t action = store_or_get_action(key_buffer[i].event.pressed, key_buffer[i].event.key);
|
|
|
|
process_action(&(key_buffer[i]), action);
|
2016-12-17 01:50:28 +06:00
|
|
|
#else
|
2019-08-31 00:19:03 +06:00
|
|
|
register_code16(key_buffer[i]);
|
|
|
|
send_keyboard_report();
|
2016-12-10 20:11:59 +06:00
|
|
|
#endif
|
2019-08-31 00:19:03 +06:00
|
|
|
}
|
2016-12-10 04:49:11 +06:00
|
|
|
}
|
|
|
|
|
2019-08-31 00:19:03 +06:00
|
|
|
buffer_size = 0;
|
2016-12-10 04:49:11 +06:00
|
|
|
}
|
|
|
|
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
#define ALL_COMBO_KEYS_ARE_DOWN (((1 << count) - 1) == combo->state)
|
2019-08-31 00:19:03 +06:00
|
|
|
#define KEY_STATE_DOWN(key) \
|
|
|
|
do { \
|
|
|
|
combo->state |= (1 << key); \
|
|
|
|
} while (0)
|
|
|
|
#define KEY_STATE_UP(key) \
|
|
|
|
do { \
|
|
|
|
combo->state &= ~(1 << key); \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
static bool process_single_combo(combo_t *combo, uint16_t keycode, keyrecord_t *record) {
|
|
|
|
uint8_t count = 0;
|
|
|
|
uint8_t index = -1;
|
|
|
|
/* Find index of keycode and number of combo keys */
|
|
|
|
for (const uint16_t *keys = combo->keys;; ++count) {
|
|
|
|
uint16_t key = pgm_read_word(&keys[count]);
|
|
|
|
if (keycode == key) index = count;
|
|
|
|
if (COMBO_END == key) break;
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
}
|
2019-08-31 00:19:03 +06:00
|
|
|
|
|
|
|
/* Continue processing if not a combo key */
|
|
|
|
if (-1 == (int8_t)index) return false;
|
|
|
|
|
|
|
|
bool is_combo_active = is_active;
|
|
|
|
|
|
|
|
if (record->event.pressed) {
|
|
|
|
KEY_STATE_DOWN(index);
|
|
|
|
|
|
|
|
if (is_combo_active) {
|
|
|
|
if (ALL_COMBO_KEYS_ARE_DOWN) { /* Combo was pressed */
|
|
|
|
send_combo(combo->keycode, true);
|
|
|
|
drop_buffer = true;
|
|
|
|
}
|
|
|
|
}
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
} else {
|
2019-08-31 00:19:03 +06:00
|
|
|
if (ALL_COMBO_KEYS_ARE_DOWN) { /* Combo was released */
|
|
|
|
send_combo(combo->keycode, false);
|
|
|
|
} else {
|
|
|
|
/* continue processing without immediately returning */
|
|
|
|
is_combo_active = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
KEY_STATE_UP(index);
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
}
|
2016-12-10 04:49:11 +06:00
|
|
|
|
2019-08-31 00:19:03 +06:00
|
|
|
return is_combo_active;
|
2016-12-10 20:11:59 +06:00
|
|
|
}
|
|
|
|
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
#define NO_COMBO_KEYS_ARE_DOWN (0 == combo->state)
|
|
|
|
|
|
|
|
bool process_combo(uint16_t keycode, keyrecord_t *record) {
|
2019-08-31 00:19:03 +06:00
|
|
|
bool is_combo_key = false;
|
|
|
|
drop_buffer = false;
|
|
|
|
bool no_combo_keys_pressed = true;
|
|
|
|
|
|
|
|
if (keycode == CMB_ON && record->event.pressed) {
|
|
|
|
combo_enable();
|
|
|
|
return true;
|
|
|
|
}
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
|
2019-08-31 00:19:03 +06:00
|
|
|
if (keycode == CMB_OFF && record->event.pressed) {
|
|
|
|
combo_disable();
|
|
|
|
return true;
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
}
|
2016-12-17 01:50:28 +06:00
|
|
|
|
2019-08-31 00:19:03 +06:00
|
|
|
if (keycode == CMB_TOG && record->event.pressed) {
|
|
|
|
combo_toggle();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!is_combo_enabled()) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (current_combo_index = 0; current_combo_index < COMBO_COUNT; ++current_combo_index) {
|
|
|
|
combo_t *combo = &key_combos[current_combo_index];
|
|
|
|
is_combo_key |= process_single_combo(combo, keycode, record);
|
|
|
|
no_combo_keys_pressed = no_combo_keys_pressed && NO_COMBO_KEYS_ARE_DOWN;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (drop_buffer) {
|
|
|
|
/* buffer is only dropped when we complete a combo, so we refresh the timer
|
|
|
|
* here */
|
|
|
|
timer = timer_read();
|
|
|
|
dump_key_buffer(false);
|
|
|
|
} else if (!is_combo_key) {
|
|
|
|
/* if no combos claim the key we need to emit the keybuffer */
|
|
|
|
dump_key_buffer(true);
|
|
|
|
|
|
|
|
// reset state if there are no combo keys pressed at all
|
|
|
|
if (no_combo_keys_pressed) {
|
|
|
|
timer = 0;
|
|
|
|
is_active = true;
|
|
|
|
}
|
|
|
|
} else if (record->event.pressed && is_active) {
|
|
|
|
/* otherwise the key is consumed and placed in the buffer */
|
|
|
|
timer = timer_read();
|
|
|
|
|
|
|
|
if (buffer_size < MAX_COMBO_LENGTH) {
|
2016-12-17 01:50:28 +06:00
|
|
|
#ifdef COMBO_ALLOW_ACTION_KEYS
|
2019-08-31 00:19:03 +06:00
|
|
|
key_buffer[buffer_size++] = *record;
|
2016-12-17 01:50:28 +06:00
|
|
|
#else
|
2019-08-31 00:19:03 +06:00
|
|
|
key_buffer[buffer_size++] = keycode;
|
2016-12-17 01:50:28 +06:00
|
|
|
#endif
|
2019-08-31 00:19:03 +06:00
|
|
|
}
|
2016-12-10 20:11:59 +06:00
|
|
|
}
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
|
2019-08-31 00:19:03 +06:00
|
|
|
return !is_combo_key;
|
Switch process_combo to using global register and timer (#2561)
Since combos keep local state about what keys have been previously pressed, when combos are layered, multiple keypresses will register for any key with multiple combos assigned to it. In order to fix this, I switched process_combo to use a global keycode / keyrecord register and timer. When a keypress is consumed by a combo, it gets stored in the register and the timer is updated; when the next keypress takes too long or a key is pressed that isn't part of any combo, the buffer is emitted and the timer reset. This has a few side effects. For instance, I couldn't _not_ fix combo keys printing out of order while also fixing this bug, so combo keys print in order correctly when a combo fails. since combos no longer have local timers, the logic around when combos time out has changed. now that there is a single timer pressing any combo key (including one in a different combo) will reset the timer for all combos, making combo entry a little more lenient. Since combos no longer have local keycode / keyrecord state, there is an edge case where incomplete combo keys can be consumed. if you have a combo for a+s = tab and a combo for b+n = space, if you press a+b+n, only a space will be emitted. This is because when b+n completes successfully, it drops the register.
2019-04-09 03:07:15 +06:00
|
|
|
}
|
|
|
|
|
|
|
|
void matrix_scan_combo(void) {
|
2019-08-31 00:19:03 +06:00
|
|
|
if (b_combo_enable && is_active && timer && timer_elapsed(timer) > COMBO_TERM) {
|
|
|
|
/* This disables the combo, meaning key events for this
|
|
|
|
* combo will be handled by the next processors in the chain
|
|
|
|
*/
|
|
|
|
is_active = false;
|
|
|
|
dump_key_buffer(true);
|
|
|
|
}
|
2016-12-17 01:50:28 +06:00
|
|
|
}
|
2019-07-16 14:37:19 +06:00
|
|
|
|
2019-08-31 00:19:03 +06:00
|
|
|
void combo_enable(void) { b_combo_enable = true; }
|
2019-07-16 14:37:19 +06:00
|
|
|
|
|
|
|
void combo_disable(void) {
|
|
|
|
b_combo_enable = is_active = false;
|
2019-08-31 00:19:03 +06:00
|
|
|
timer = 0;
|
2019-07-16 14:37:19 +06:00
|
|
|
dump_key_buffer(true);
|
|
|
|
}
|
|
|
|
|
|
|
|
void combo_toggle(void) {
|
|
|
|
if (b_combo_enable) {
|
|
|
|
combo_disable();
|
|
|
|
} else {
|
|
|
|
combo_enable();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-08-31 00:19:03 +06:00
|
|
|
bool is_combo_enabled(void) { return b_combo_enable; }
|