aboutsummaryrefslogtreecommitdiff
path: root/users/dennytom/chording_engine/README.md
diff options
context:
space:
mode:
Diffstat (limited to 'users/dennytom/chording_engine/README.md')
-rw-r--r--users/dennytom/chording_engine/README.md376
1 files changed, 376 insertions, 0 deletions
diff --git a/users/dennytom/chording_engine/README.md b/users/dennytom/chording_engine/README.md
new file mode 100644
index 000000000..3610b190b
--- /dev/null
+++ b/users/dennytom/chording_engine/README.md
@@ -0,0 +1,376 @@
1# README
2
3## About
4
5This is a custom combo engine. I call it chording engine mostly to differentiate it from QMK's combos. It is useful even if you are not using chording as a main input method to replace combos.
6
7Why does this exist? Typing on tiny keyboards can be challenging and you will end up relying on dances and / or combos. Pure QMK combos can be insufficient as they do not really support overlapping combos. For example, if you define 3 combos `(KC_Q, KC_W)`, `(KC_Z, KC_X)` and `(KC_Q, KC_W, KC_Z, KC_X)` and press Q, W, Z and X at the same time, all three combos will activate. Steno engines (and g Board Industries' custom steno inspired engine) solve this, however, they don't allow for comfortable typing in the traditional way. The steno chord activates only when *all* keys are lifted and makes it difficult to implement some advanced features. This engine treats each chord independently to allow for more comfortable typing experience.
8
9## TOC
10
11- [README](#readme)
12 - [About](#about)
13 - [TOC](#toc)
14 - [Start here](#start-here)
15 - [Steps](#steps)
16 - [Features](#features)
17 - [Chords](#chords)
18 - [Tap-Dance](#tap-dance)
19 - [Pseudolayers](#pseudolayers)
20 - [Control chords](#control-chords)
21 - [Settings up JSON definition](#settings-up-json-definition)
22 - [Keyboard and engine parameters](#keyboard-and-engine-parameters)
23 - [Pseudolayers](#pseudolayers-1)
24 - [Supported keycodes](#supported-keycodes)
25 - [Leader Key](#leader-key)
26 - [Extra code](#extra-code)
27 - [Further details](#further-details)
28 - [Implementation](#implementation)
29 - [Internal keycodes](#internal-keycodes)
30 - [Chords](#chords-1)
31 - [Caveats](#caveats)
32
33## Start here
34
35This engine therefore uses python parser that translates a JSON definition of keyboard specific information and keymap definition and produces `keymap.c`. Every function on this keymap is a chord (combo). The resulting keymap file is long and I do not encourage you to edit it. All you should have to edit is the JSON file. To produce the keymap file, run
36
37```sh
38./parser.py keymap_def.json keymap.c
39```
40
41To prepare the keymap JSON definition, you can use on of my keymaps as a starting point. I have on for butterstick and for georgi. There is also a JSON schema that has some examples and sane defaults. All details are explained in the next section. The parser tries to validate some of the things that the JSON schema can not. Finally there is a JSON in the tests folder that has at least one example of every feature.
42
43Watch out, you can not name your JSON file `keymap.json` if you place in the keymap folder. QMK creates `keymap.json` as a part of compilation process and if you already have one, it gets confused.
44
45## Steps
46
47When setting up a new keyboard, follow the steps:
48
491. Make a new directory for your keymap as QMK's documentation describes.
502. Write your JSON. Name it anything but `keymap.json`.
513. Depending on the keyboard / keymap, create `rules.mk` (follow QMK's documentation and note that if the keyboard's `rules.mk` include custom source files, this is the place you can remove them).
524. Use my python parser to generate the `keymap.c`. Run it from the `/users/dennytom/chording_engine` directory as it is using relative paths to some extra files.
535. Follow QMK's documentation to compile and flash your firmware.
54
55## Features
56
57### Chords
58
59Once again, *everything* on this keymap is a chord. Even sending `KC_Q` is done by pressing a single key chord. Chord gets activated after all it's keys get pressed. Only the longest chord gets activated. The order of the pressed keys *does not matter*, only the fact they have been pressed within the same time frame. An active chord gets deactivated if *any* of it's keys gets depressed. To activate the same single chord again, *all* it's keys have to be depressed and pressed again. With a few exceptions chords are independent of each other. No matter if some chords are currently active and some not, others can be activated or deactivated without affecting each other's state. *If you press keys to belonging to multiple different, non-overlapping chords, all get activated in the order they are defined in the keymap.*
60
61### Tap-Dance
62
63To make it even stranger, all chords are technically tap-dance chords. They are relatively simple state machines that execute a specific function every time they change state. For simplicity and optimization purposes, there are a few prewritten functions that implement common features like "send a single key" or "lock". Any number of chords can be "in dance" at any given moment without affecting each other's state. Custom dances can be easily added. Check out the `state_machine.png` to see all the states any chord can be in.
64
65### Pseudolayers
66
67Only one QMK layer is used. Following the butterstick's default keymap's example, the chording engine is using pseudolayers. The main difference to QMK's layers is that only one pseudolayer can be active at each time (meaning you can not use `KC_TRANS`, I actually don't know what will happen if you do). Chords can be activated only if they are on the currently active pseudolayer. Chords that are currently active do not get deactivated if the pseudolayer changes and will deactivate if any of their keys gets depressed even no matter the current pseudolayer. Locked chords (see below) and chords on the `ALWAYS_ON` pseudolayer can be activated anytime.
68
69### Control chords
70
71The engine implements a number of ways of changing how chords behave:
72
73* **Lock**: Similarly to QMK's lock, the next chord activated after the Lock chord will not deactivate on release of any of its keys, it will deactivate when all its keys get pressed again. Any number of chords can be locked at the same time. To make sure a locked chord can be unlocked, it can activate no matter the current pseudolayer. A chord can be locked mid dance.
74* **One shots**: Chords that send keycodes and chords that turn on pseudolayers can be one shots. If tapped, they will lock (stay active) until the next keycode gets sent, *not necessarily when the next chord gets activated*. If held, they will deactivate on release *even if no keycode got sent*.
75* **Tap-Hold**: Also called key-layer dance and key-key dance. Either sends a defined keycode on tap and temporarily switches pseudolayer on hold *or* sends two different keycodes on tap and hold.
76* **Command mode**: After getting activated for the first time, the keyboard switches to command mode. All *keycodes* that would get registered get buffered instead. After activating the Command mode chord for the second time, all buffered keycodes get released at the same time allowing for key combination that would be hard or impossible to press. The Command mode only affects keycodes. It is therefore possible to change pseudolayers or activate / deactivate other chords while in Command mode. While multiple Command mode chords can be defined, they would not be independent. The keyboard either is or is not in command mode and there is only one buffer.
77* **Leader key**: Just like pure QMK's Leader key, this allows you to add functions that get executed if the Leader key and a specific sequence of keycodes gets registered in a predefined order in a short timeframe. For example `:wq` can send `Ctrl+S` and `Ctrl+W` in a quick succession. While multiple Leader keys can be defined, they all would access the same list of sequences.
78* **Dynamic macro**: A sequence of keycodes can be recorded and stored in the RAM of the keyboard and replayed.
79
80## Settings up JSON definition
81
82The JSON definition has 3 main sections. The elements `keys`, `parameters` and `layers` teach the engine about the details of your keyboard and set its parameters. The elements `pseudolayers`, `leader_sequences` and `chord_sets` define your keymap. Finally, the elements `extra_code` and `extra_dependencies` allow you to include more code to extend the capabilities of the engine.
83
84### Keyboard and engine parameters
85
86I do not have experience with stenography, so the the steno keycodes are hard for me to remember. That is why the keymap is using new keycodes TOP1, TOP2, ... .
87
88```c
89 "keys": ["TOP1", "TOP2", "TOP3", ...]
90```
91
92You can name these however you like as long as they do not crash with QMK's keycodes.
93
94*The chording engine in it's current implementation can handle up to 64 keys. If you need to support more, contact me (email or u/DennyTom at Reddit).*
95
96All timings, maximum lengths for macros, command mode and leader function are defined in `keyboard_parameters` field. Almost all should be pretty self-explanatory.
97
98My keyboards are small, so I only use the engine, but you might want to use layers that combine chord-able keys and traditional QMK keys or layers with advanced keycodes, for example for stenography. The array `layers` defines all the parser needs to know:
99
100```json
101"layers": [
102 {
103 "type": "auto"
104 },
105 {
106 "type": "manual",
107 "keycodes": ["KC_1", "KC_2", "KC_3", "KC_4", "KC_5", "KC_6", "KC_7", "KC_8", "KC_9", "KC_0",
108 "KC_Q", "KC_W", "KC_E", "KC_R", "KC_T", "KC_Y", "KC_U", "KC_I", "KC_O", "KC_P"
109 ]
110 },
111 {
112 "type": "manual",
113 "keycodes": ["KC_1", "KC_2", "KC_3", "KC_4", "KC_5", "KC_6", "KC_7", "KC_8", "KC_9", "KC_0",
114 "BOT1", "BOT2", "BOT3", "BOT4", "BOT5", "BOT6", "BOT7", "BOT8", "BOT9", "BOT0"]
115 }
116 ]
117```
118
119This example defines 3 layers, one that is automatically populated with chording engine's internal keycodes, second that is populated with QMK's keycodes and third that uses both internal and QMK's keycodes. The layers do not have names, you have to access them with `TO(1)` and `TO(0)`.
120
121Some keyboards mangle the order of keycodes when registering them in the layers. For that fill up the `layout_function_name` with the name of function / macro. If your keyboard does not do it, leave that string empty.
122
123### Pseudolayers
124
125Array `pseudolayers` defines the keymap per pseudolayer. Each field has to contain the name for the layer and the list of chords.
126
127```JSON
128"pseudolayers": [
129 {
130 "name": "QWERTY",
131 "chords": [
132 {
133 "type": "simple",
134 "keycode": "SPACE",
135 "chord": ["BOT1", "BOT0"]
136 },
137 {
138 "type": "visual",
139 "keycode": "CLEAR_KB",
140 "chord": [
141 "X", "", "", "", "", "", "", "", "", "X",
142 "X", "", "", "", "", "", "", "", "", "X",
143 ]
144 },
145 {
146 "type": "visual_array",
147 "keys": ["TOP1", "TOP2", "TOP3"],
148 "dictionary": [
149 ["X", "X", " ", "ESC"],
150 [" ", "X", "X", "TAB"],
151 ["X", "X", "X", "ENTER"]
152 ]
153 },
154 {
155 "type": "chord_set",
156 "set": "rows",
157 "keycodes": [
158 "Q", "W", "E", "R", "T", "Y", "U", "I", "O", "P",
159 "A", "S", "D", "F", "G", "H", "J", "K", "L", ";",
160 "Z", "X", "C", "V", "B", "N", "M", ",", ".", "/"
161 ]
162 }
163 ]
164 }
165]
166```
167
168The array `chord` defines chords. You can either use simple chord and list all the keys that have to pressed at the same time, or use the visual chord and place `"X"` over keys that will be part of the chord. You can also use `visual_array` to define a number of chords in a visual way on a subset of keys defined in the `keys` array. Finally, you can use `chord_set` to define a number of chords following a pattern that was set in the `chord_sets` array in the root object like this:
169
170```json
171"chord_sets": [
172 {
173 "name": "rows",
174 "chords": [
175 ["TOP1"], ["TOP2"], ["TOP3"], ["TOP4"], ["TOP5"], ["TOP6"], ["TOP7"], ["TOP8"], ["TOP9"], ["TOP0"]
176 ["TOP1", "BOT1"], ["TOP2", "BOT2"], ["TOP3", "BOT3"], ["TOP4", "BOT4"], ["TOP5", "BOT5"], ["TOP6", "BOT6"], ["TOP7", "BOT7"], ["TOP8", "BOT8"], ["TOP9", "BOT9"], ["TOP0", "BOT0"],
177 ["BOT1"], ["BOT2"], ["BOT3"], ["BOT4"], ["BOT5"], ["BOT6"], ["BOT7"], ["BOT8"], ["BOT9"], ["BOT0"]
178 ]
179 },
180 {
181 "name": "cols",
182 "chords": [
183 ["TOP1", "TOP2"], ["TOP2", "TOP3"], ["TOP3", "TOP4"], ["TOP4", "TOP5"], ["TOP5", "TOP6"], ["TOP6", "TOP7"], ["TOP7", "TOP8"], ["TOP8", "TOP9"], ["TOP9", "TOP0"],
184 ["TOP1", "TOP2", "BOT1", "BOT2"], ["TOP2", "TOP3", "BOT2", "BOT3"], ["TOP3", "TOP4", "BOT3", "BOT4"], ["TOP4", "TOP5", "BOT4", "BOT5"], ["TOP5", "TOP6", "BOT5", "BOT6"], ["TOP6", "TOP7", "BOT6", "BOT7"], ["TOP7", "TOP8", "BOT7", "BOT8"], ["TOP8", "TOP9", "BOT8", "BOT9"], ["TOP9", "TOP0", "BOT9", "BOT0"],
185 ["BOT1", "BOT2"], ["BOT2", "BOT3"], ["BOT3", "BOT4"], ["BOT4", "BOT5"], ["BOT5", "BOT6"], ["BOT6", "BOT7"], ["BOT7", "BOT8"], ["BOT8", "BOT9"], ["BOT9", "BOT00"],
186 ]
187 }
188]
189```
190
191
192
193You might notice that the code tries to do a few clever things when parsing keycodes:
194
195* If the keycode would be just a character basic keycode, it tries to allow the use of shortcuts. `Q` will get replaced with `KC_Q`, `,` becomes `KC_COMMA`. This *should* work for all KC_ keycodes unless I missed some.
196* `MO()` and `DF()` macros work the same way for pseudolayers as they would for layers in pure QMK.
197* `O()` is a shortcut for `OSK()` or `OSL()`.
198* `STR('...')` sends a string. Careful with quoting.
199* Special chords like Command mode have their own codes like `CMD`.
200* The empty strings get ignored.
201
202### Supported keycodes
203
204* **`X`** or **`KC_X`**: Send code `KC_X` just like a normal keyboard.
205
206* **`STR("X")`**: Send string "x" on each activation of the chord. Once again, watch out for quoting and escaping characters. If you want special characters (especially quotes) in your string, look up Python reference for string literals and experiment. Also, because of how the string gets parsed, it is not possible to use `(` in the string.
207
208* **`MO(X)`**: Temporary switch to pseudolayer `X`. Because only one pseudolayer can be active at any moment, this works by switching back to the pseudolayer the chord lives on on deactivation. If you chain `MO()`s on multiple pseudolayers and deactivate them in a random order, you might end up stranded on a pseudolayer. I recommend adding `CLEAR` somewhere on `ALWAYS_ON` pseudolayer just in case.
209
210* **`MO(X,Y)`**: Temporary switch to pseudolayer `Y`. Switches to pseudolayer `X` on deactivation. Especially useful when you want to put the `MO()` chord on `ALWAYS_ON`.
211
212* **`DF(X)`**: Permanent switch to pseudolayer `X`.
213
214* **`TO(X)`**: Switches the QMK layer to `X`.
215
216* **`O(X)`**: One-shot key `X` (if `X` starts with `"KC_"`) or one-shot layer `X` (otherwise) . Both have retro tapping enabled.
217
218* **Tap-holds**
219
220 * **`KK(X, Y)`**: Pulses code `X` on tap and code `Y` on hold.
221 * **`KL(X, Y)`**: Pulses code `X` on tap and switches to pseudolayer `Y` on hold. If during the hold no key gets registered, the code `X` will get sent instead (similar to QMK's retro tapping).
222 * **`KM(X, Y)`**: Same as `KK()` but meant for modifiers on hold. Instead of a timer to figure out tap-hold, uses retro tapping like behavior just like `KL()`. This has issues with GUI and ALT as they often have a meaning.
223 * The chording engine determines if you are holding a chord based on a *global* timer. If you start holding a tap-hold chord and very quickly start tapping other chords, the hold might not activate until a short moment *after the last* chord when the timer expires. If you are running into this, adjust timeouts or wait a brief moment after pressing the chord to make sure it switches into the hold state before pressing other chords.
224
225* **Autoshift**
226
227 * **`AS(X)`**: Pulses code `X` on tap and Pulses left shift + `X` on hold.
228 * **`AT`** : Toggles autoshift for all autoshift chords. If off, all `AS` chords act like `KC` chords.
229
230* **`LOCK`**: The lock key. Since tap-dances of chords are independent, it is possible to lock a chord *anywhere in it's dance if you time it right!*. If that happens, use the `CLEAR` chord or restart your keeb.
231
232* **`CMD`**: The command mode. The number of keycodes that can be buffered is defined in in `command_max_length`.
233
234* **`LEAD`**: The leader key. The maximum length of the sequences needs to be defined in `keyboard_params`. You can use `leader_sequences` array to add sequences:
235
236 ```json
237 "leader_sequences": [
238 {
239 "name": "fn_L1",
240 "function": "void fn_L1(void) { SEND(KC_LCTL); SEND(KC_LALT); SEND(KC_DEL); }",
241 "sequence": ["KC_Q", "KC_Z"]
242 }
243 ]
244 ```
245
246 When the engine notices the sequence, it will call the function defined in the field `name`. You can either define it in the `function` field, in the field `extra_code` or in an external file that you then have to insert manually or using the `extra_dependencies` array. The parser copy-pastes the contents `extra_code` of all files specified in the `extra_dependencies` array in the `keymap.c`.
247
248* **`M(X, VALUE1, VALUE2)`**: A custom macro. Adds a chord that will use function `X` and with `chord.value1 = VALUE1; chord.value2 = VALUE2;`. The function `X` can be arbitrary C function, go crazy. Just like with the leader sequences, you have to insert the code into the generated `keymap.c` manually or through `extra_code` or `extra_dependencies`. The following example defines a macro that acts exactly like `KC_MEH` (the chording engine *should* support `KC_MEH`, this is just an example):
249
250 ```c
251 void fn_M1(const struct Chord* self) {
252 switch (*self->state) {
253 case ACTIVATED:
254 key_in(KC_LCTL);
255 key_in(KC_LSFT);
256 key_in(KC_LALT);
257 break;
258 case DEACTIVATED:
259 key_out(KC_LCTL);
260 key_out(KC_LSFT);
261 key_out(KC_LALT);
262 break;
263 case FINISHED:
264 case FINISHED_FROM_ACTIVE:
265 break;
266 case RESTART:
267 key_out(KC_LCTL);
268 key_out(KC_LSFT);
269 key_out(KC_LALT);
270 break;
271 default:
272 break;
273 }
274 }
275 ```
276
277 Since this feels like it would be the most common way to use this feature, I wrote a macro for this:
278
279* **`MK(X1, X2, ...)`**: Acts like `KC()` except it registers / unregisters all `X1`, `X2`, ... codes at the same time.
280
281* **`D(X1, X2, ...)`**: A basic keycode dance. If tapped (or held), registers `X1`. If tapped and then tapped again (or held), registers `X2`, ... It *cannot* be combined with tap-hold, however holding will result in repeat. You can put in as many basic keycodes as you want, but the macro will break if you go beyond 256. It will try to expand shortened keycodes. Advanced keycodes are not supported.
282
283* **`DM_RECORD`, `DM_NEXT`, `DM_END`, `DM_PLAY`**: Start recording a dynamic macro. Once you start recording, basic keycodes will get stored. When replaying the macro, all keys you press before `DM_NEXT` or `DM_END` will get pressed at the same time. For example the sequence `DM_RECORD`, `KC_CTRL`, `KC_A`, `DM_NEXT`, `KC_BSPC`, `DM_END` will record a macro that when played will execute the sequence Ctrl+a, Backspace. `dynamic_macro_max_length` defines the maximum length of the macro to be recorded. You can increase it for the price of RAM. The example above requires 4 units of length to be saved (Ctrl, A, next, Backspace).
284
285* **`CLEAR_KB`**: clears keyboard, sets all chords to the default state and switches the pseudolayer to the default one. Basically the emergency stop button.
286
287* **`RESET`**: Go to the DFU flashing mode.
288
289**Caveat** of the current implementation is that the tap-hold, `MK` and `D` keycodes can not accept any of the keycodes that have some sort a function like dynamic macro specific chords, `CLEAR_KB`, `RESET`, `LOCK`, `AT`, ...
290
291### Leader Key
292
293The sequences are not defined by the *keys* you press but by the *keycodes* that get intercepted. The length of the sequence must be equal or shorter than the maximum (defined in `keyboard.inc`). Currently, the timeout for the leader sequence refreshes after each key pressed. If the sequence is not in the database, nothing will happen.
294
295### Extra code
296
297Extra C code needed to define custom chords can be added by quoting in in the `extra_code` element or by saving it in another header file and including it using the `extra_dependencies` element:
298
299```json
300{
301 "extra_code": "void double_dance(const struct Chord* self) { ... }\n",
302 "extra_dependencies": ["my_header.h"]
303}
304```
305
306
307
308## Further details
309
310### Implementation
311
312The source files are split into several files. `engine.part.1`, `engine.part.2` and `engine.part.3` contain C code that defines the Chord structure, implementations for all provided functions and the engine itself. `parser.py` generates keyboard and keymap dependent code. The file `chord.py` contains most of the logic required to properly translate chords from the JSON to the C code. I rarely write in python, if you have improvements, let me know, *please*.
313
314### Internal keycodes
315
316When `process_record_user()` gets one of the internal keycodes, it returns `true`, completely bypassing keyboard's and QMK's `process_record` functions. *All other* keycodes get passed down to QMK's standard processing.
317
318### Chords
319
320Each chord is defined by a constant structure, a function and two non-constant `int` variables keeping the track of the chord's state:
321
322```c
323struct Chord {
324 uint32_t keycodes_hash;
325 uint8_t pseudolayer;
326 uint8_t* state;
327 uint8_t* counter;
328 uint16_t value1;
329 uint8_t value2;
330 void (*function) (const struct Chord*);
331};
332
333uint8_t state_0 = IDLE;
334uint8_t counter_0 = 0;
335void function_0(struct Chord* self) {
336 switch (*self->state) {
337 case ACTIVATED:
338 register_code(self->value1);
339 break;
340 case DEACTIVATED:
341 unregister_code(self->value1);
342 break;
343 case FINISHED:
344 case PRESS_FROM_ACTIVE:
345 break;
346 case RESTART:
347 unregister_code(self->value1);
348 break;
349 default:
350 break;
351 }
352}
353const struct Chord chord_0 PROGMEM = {H_TOP1, QWERTY, &state_0, &counter_0, KC_Q, 0, function_0};
354```
355
356All chords have to be added to `list_of_chord` array that gets regularly scanned and processed. The function doesn't actually activate on all state changes, there are a few more like `IDLE` (nothing is currently happening to the chord) or `IN_ONE_SHOT` (the chord is one shot and is currently locked). Those are all necessary for internal use only. The ones you have to worry about are
357
358* `ACTIVATED`: Analogous to a key being pressed (this includes repeated presses for tap-dance)
359* `DEACTIVATED`: Analogous to a key being depressed (also can be repeated)
360* `FINISHED`: Happens if the chord got deactivated and then the dance timer expired.
361* `PRESS_FROM_ACTIVE`: Happens if the chord was active when the dance timer expired. Meaning you at least once activated the chord and then kept holding it down. Useful to recognize taps and holds.
362* `FINISHED_FROM_ACTIVE`: Happens *after* `PRESS_FROM_HOLD` if the chord is still active when the dance timer expires for the second time. Can be combined with the `counter` to recognize even longer presses. Useful if you want to recognize long presses, for example for autoshift functionality. In `keyboard.inc` you can set `LONG_PRESS_MULTIPLIER` to set how many times does dance timer have to expire for the autoshift to trigger.
363* `RESTART`: The dance is done. Happens immediately after `FINISHED` or on chord deactivation from `FINISHED_FROM_ACTIVE`. Anything you have to do to get the chord into `IDLE` mode happens here.
364
365The chords change states based on external and internal events. Anytime a chord's function is activated, it may change it's own state. Also, on certain events, the chording engine will trigger the functions of all chords in a specific state and *if the chords' state hasn't changed* it will then change it appropriately. The default behavior when a chord changes state is described by the following diagram:
366
367![state machine diagram](state_machine.png)
368The colors differentiate in which function the change happens, see `state_machine.dot` for a bit more detail. Black arrows happen in more than one function. Arrows without a label happen immediately.
369
370You can see that the diagram is not exhaustive. For example nothing leads into `IN_ONE_SHOT`. That is because the chord's function can change the chord's state. This is useful for some advanced chords that break the default behavir (one-shots) and for optimization (chords that just send `KC_X` do not need to ever go into dance).
371
372## Caveats
373
374Each chord stores as much as possible in `PROGMEM` and unless it needs it, doesn't allocate `counter`. However it still has to store it's `state` and sometimes the `counter` in RAM. If you keep adding more chords, at one point you will run out. If your firmware fits in the memory and your keyboard crashes, try optimizing your RAM usage.
375
376Also, the code is not perfect. I keep testing it, but can not guarantee that it is stable. Some functions take (very short but still) time and if you happen to create keypress event when the keyboard can not see it, a chord can get stuck in a funny state. That is especially fun if the pseudolayer changes and you can not immediately press it again. Just restart the keyboard or push the key a few times.
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-01 09:28:25 +0000