Declaring LayerCount as a weak symbol in layers.cpp lets us override
it if the CREATE_KEYMAP macro is used to define the keymap in the
sketch file, but still allows old sketch files to compile without
errors.
Still some changes necessary to allow old sketches to work
properly (Layer.on() will abort before doing anything).
This macro allows the definition of the LayerCount variable and the
keymaps[] array together. It shouldn't break old sketches, but this is
probably not all that's necessary; LayerCount still doesn't get
initialized outside the macro.
For all cases outside of Kaleidoscope itself, we are good with the value of
`highestLayer`, and do not need to re-scan the layer state. For this reason -
upon @obra's suggestion - rename `Layer.highest()` to `Layer.top()`, and the old
`Layer.top()` to `Layer.updateHighestLayer()`, and make the latter private, and
update the `highestLayer` member variable instead of returning the number.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
`layer_getKey` was introduced in 6d641e7fc5, by
mistake, it was never implemented. Remove it now to avoid any possible
confusion.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Sometimes we would like to know the highest active layer, which is available in
the `highestLayer` private variable, and via `.top()` too. We do not want to
make `highestLayer` public, because we want to be the only ones changing it. And
while `top()` gets us roughly the same information, it does so at a cost. For a
lot of purposes, the cached `highestLayer` would be perfectly adequate.
The new `Layer.highest()` accessor does just this.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
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>
When we change layers, we want to update the key cache for the whole keyboard,
so that LED modes and other things that depend on all keys being up-to-date will
work as expected.
Do the same at `Kaleidoscope.setup` time, so we start with a good state too.
This fixeskeyboardio/Kaleidoscope-Numlock#7.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of storing the layer for each key, store the keycode, so that lookups
are considerably faster (one array lookup instead of two). This saves us almost
a full millisecond per scan cycle. Furthermore, inline `Layer_.lookup`, saving
us even more time.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This changes how key caching & lookup works: instead of updating the whole key
cache whenever we change the layer state, we update each key before they are
pressed or released. This allows us to have two different ways in which layers
can work:
- Keys still held when releasing the layer key will be masked out until they are
released. (This is the current behaviour)
- Keys held will repeat the keycode they had when they toggled on, even if the
layer key gets released prior to this other key, while other keys will not be
affected.
One can toggle between the two modes by setting
`Kaleidoscope.repeat_first_press` to `true` (second behaviour) or `false` (first
behaviour).
For now, the default behaviour is left unchanged.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
We want to allow plugins to change how keys are looked up - or where they are
looked up from -, and for this, the way we do that final lookup from `keymaps`
or elsewhere, must be overrideable.
We do this by having a `getKey` function pointer in the `Layer_` class, which
defaults to `getKeyFromPROGMEM`. Any plugin, or sketch, can change where
`getKey` points to, and thereby change the way keys are looked up.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The plugin.h header only defined the KaleidoscopePlugin class, and while
there was a reason it was separate from Kaleidoscope.h, that reason is
long gone. Merge it there, and remove any reference to plugin.h, as it
is not needed anymore.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of going through all the active layers each time we are looking for a
key, whenever we switch layers, compute the effective keymap, and store the
indexes. This makes the lookup a considerably faster operation, and lookups
happen far more often than layer switching.
This comes at a cost of ROWS*COLS amount of memory, and a bit of code, but on
the flip side, the lookup operation is now O(1), which is a very nice property
to have, if you want responsiveness. Changing layers is marginally slower,
however, but even with 32 active layers, doing the computation once, instead of
potentially many dozens of time, is still worth it.
We could further reduce the memory requirements if we stored more columns per
byte, but that's for a future optimization.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of always iterating through all layers, which slows us down
considerably, keep track of the highest active one, and start from there.
This has a VERY noticeable impact on the speed at which we finish a scan cycle.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The layer handling is a core functionality, it should be active at all times,
and should be at the very end, before the default event handler. Otherwise there
may be ordering issues, when a plugin wants to return layer keys from its own
event handler.
This also saves us a couple of bytes of both code and data, as an additional
bonus!
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of having a primary and a temporary layer, store the state of at
most 32 layers in a bitfield. These can be individually turned on and
off, and key lookup starts from the top, and goes downwards until the
default layer to find a non-transparent key.
This allows one to reuse a partially transparent layer: set the default,
and the transparent parts will be reused. The numpad layer was updated
accordingly.
Having an interface to the layer switching things also makes it easier
to build other behaviour on top of these.
As part of the rework, layer handling was moved to a separate file, and into its
own, full-blown handler. Furthermore, we now use a single bit for all keymap
events.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Michael Richters
Jesse Vincent
Gergely Nagy
Jesse Vincent
Gergely Nagy