With the new implementation, there are two lookup functions, because we have two caches, and different parts of the firmware will want to use either this or that (or perhaps both, in rare cases). First of all, we use caches because looking up a key through all the layers is costy, and the cost increases dramatically the more layers we have. Then, we have the `effectiveKeymapCache`, because to have layer behaviours we want, that is, if you hold a key on a layer, release the layer key but continue holding the other, we want for the layered keycode to continue repeating. At the same time, we want other keys to not be affected by the now-turned-off layer. So we update the keycode in the cache on-demand, when the key is pressed or released. (see the top of `handleKeyswitchEvent`). On the other hand, we also have plugins that scan the whole keymap, and do things based on that information, such as highlighting keys that changed between layers. These need to be able to look at a state of where the keymap *should* be, not necessarily where it is. The `effectiveKeymapCache` is not useful here. So we use a `keymapCache` which we update whenever layers change (see `Layer.on` and `Layer.off`), and it updates the cache to show how the keymap should look, without the `effectiveKeymapCache`-induced behaviour. Thus, if we are curious about what a given key will do, use `lookup`. If we are curious what the active layer state describes the key as, use `lookupUncached`. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>pull/174/head
parent
b8f8c9b3d5
commit
29a8b95615
Loading…
Reference in new issue