alpha
/
Kaleidoscope
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'eb02ca5fe6'
${ noResults }
Kaleidoscope/src/hooks.h

23 lines
747 B
Raw Normal View History Unescape

Small hook rework Two things are done here: loop() hooks are introduced, and both loop and event handler hooks are pre-allocated for HOOK_MAX (64 by default) elements. Two helpers are introduced too, that make it easier to append a new hook to the end of these arrays. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
#pragma once
#include <Arduino.h>
A way to restart the event handler with a different code There are scenarios where one would want to inject a keycode into the event handler chain, restart the processing from scratch, but with a keycode different than what the lookup would normally yield. For example, with one-shot modifiers, a feature one may wish is to be able to turn the one-shotness off, and have them act as normal modifiers. This is easily done, if we can remove the one-shot markup, and let the event handler process the resulting code as-is. This makes that possible: in a custom event handler, just call handle_key_event() with the first argument set to the desired code, and the rest left unchanged. This makes it possible to inject events: not just register keycodes with the HID, but inject synthetic events, something much more powerful. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
#include "key_defs.h"
Small hook rework Two things are done here: loop() hooks are introduced, and both loop and event handler hooks are pre-allocated for HOOK_MAX (64 by default) elements. Two helpers are introduced too, that make it easier to append a new hook to the end of these arrays. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
#define HOOK_MAX 64
Event hooks reworked, again Instead of returning a bool, to signal whether further processing should be done, return a Key. Reason being, if we want to replace a key with another, for subsequent handlers, it is a lot easier if we can modify what gets passed along, than it is to inject a key, and try to avoid loops and infinite recursion. Nevertheless, injecting keys is still possible. This is not immediately useful for the core firmware, but makes it trivially easy to upgrade keys from their normal behaviour to something special: for example, a one-shot handler can auto-promote modifiers to one-shot, simply by scheduling a promoter handler before the real one. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
typedef Key (*custom_handler_t)(Key mappedKey, byte row, byte col, uint8_t keyState);
Small hook rework Two things are done here: loop() hooks are introduced, and both loop and event handler hooks are pre-allocated for HOOK_MAX (64 by default) elements. Two helpers are introduced too, that make it easier to append a new hook to the end of these arrays. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
extern custom_handler_t eventHandlers[HOOK_MAX];
hooks: Double-registration protection In most cases, one only wants a single copy of a hook. On the other hand, plugins that depend on other plugins, may want to make it easier for the end-user to use the plugin, and call the setup function of the dependent plugins too. In case the end-user calls the same setup function, we'd end up with hooks registered multiple times. To avoid this, protection against double-registration has been introduced. The new `event_handler_hook_use` and `loop_hook_use` functions will only allow one copy of the hook. The `event_handler_hook_append` and `loop_hook_append` functions will, on the other hand, just append the hooks, and not care about protection. The `event_handler_hook_add` and `loop_hook_add` functions are gone, but for the time being, they are aliases to the `_use` functions, until all plugins have been updated, and the aliases can be removed. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
void event_handler_hook_use (custom_handler_t hook);
void event_handler_hook_append (custom_handler_t hook);
hooks: Add a way to replace hooks To make replacing work sanely, we first NULL out both the eventHandlers and loopHooks arrays in the Keyboardio_ constructor. This allows the replace functions to just run through the whole array, and either see hook pointers there, or NULL. So they don't need to be afraid of garbage being there. This makes the replacing very easy: run through the array, and replace the first occurrence of the old hook with the new. This further simplifies addition: the old hook we pass in, will be NULL. If we run out of space, it silently fails, like before. Replacing hooks is important for cases where one wants to build features that can be toggled off, or their behaviour otherwise changed at run-time. In this case, the most efficent way is to replace the hook, which is what these new helpers allow us to do. This closes #36. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
void event_handler_hook_replace (custom_handler_t oldHook, custom_handler_t newHook);
hooks: Double-registration protection In most cases, one only wants a single copy of a hook. On the other hand, plugins that depend on other plugins, may want to make it easier for the end-user to use the plugin, and call the setup function of the dependent plugins too. In case the end-user calls the same setup function, we'd end up with hooks registered multiple times. To avoid this, protection against double-registration has been introduced. The new `event_handler_hook_use` and `loop_hook_use` functions will only allow one copy of the hook. The `event_handler_hook_append` and `loop_hook_append` functions will, on the other hand, just append the hooks, and not care about protection. The `event_handler_hook_add` and `loop_hook_add` functions are gone, but for the time being, they are aliases to the `_use` functions, until all plugins have been updated, and the aliases can be removed. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
#define event_handler_hook_add event_handler_hook_use
Small hook rework Two things are done here: loop() hooks are introduced, and both loop and event handler hooks are pre-allocated for HOOK_MAX (64 by default) elements. Two helpers are introduced too, that make it easier to append a new hook to the end of these arrays. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
Loop hooks: Run the loop hooks twice Some behaviour would benefit from knowing the last report, some would want a clear report and a way to pre-fill the next one. For this reason, we need two places to call loop hooks from: one after scanning the matrix and updating LEDs, and another after sending and clearing the report. To save space and sanity, we call the same hooks twice, but the second time, we set the `postClear` flag, which is false the first time. All users have been updated. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
typedef void (*custom_loop_t)(bool postClear);
Small hook rework Two things are done here: loop() hooks are introduced, and both loop and event handler hooks are pre-allocated for HOOK_MAX (64 by default) elements. Two helpers are introduced too, that make it easier to append a new hook to the end of these arrays. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
extern custom_loop_t loopHooks[HOOK_MAX];
hooks: Double-registration protection In most cases, one only wants a single copy of a hook. On the other hand, plugins that depend on other plugins, may want to make it easier for the end-user to use the plugin, and call the setup function of the dependent plugins too. In case the end-user calls the same setup function, we'd end up with hooks registered multiple times. To avoid this, protection against double-registration has been introduced. The new `event_handler_hook_use` and `loop_hook_use` functions will only allow one copy of the hook. The `event_handler_hook_append` and `loop_hook_append` functions will, on the other hand, just append the hooks, and not care about protection. The `event_handler_hook_add` and `loop_hook_add` functions are gone, but for the time being, they are aliases to the `_use` functions, until all plugins have been updated, and the aliases can be removed. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
void loop_hook_use (custom_loop_t hook);
void loop_hook_append (custom_loop_t hook);
hooks: Add a way to replace hooks To make replacing work sanely, we first NULL out both the eventHandlers and loopHooks arrays in the Keyboardio_ constructor. This allows the replace functions to just run through the whole array, and either see hook pointers there, or NULL. So they don't need to be afraid of garbage being there. This makes the replacing very easy: run through the array, and replace the first occurrence of the old hook with the new. This further simplifies addition: the old hook we pass in, will be NULL. If we run out of space, it silently fails, like before. Replacing hooks is important for cases where one wants to build features that can be toggled off, or their behaviour otherwise changed at run-time. In this case, the most efficent way is to replace the hook, which is what these new helpers allow us to do. This closes #36. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
void loop_hook_replace (custom_loop_t oldHook, custom_loop_t newHook);
hooks: Double-registration protection In most cases, one only wants a single copy of a hook. On the other hand, plugins that depend on other plugins, may want to make it easier for the end-user to use the plugin, and call the setup function of the dependent plugins too. In case the end-user calls the same setup function, we'd end up with hooks registered multiple times. To avoid this, protection against double-registration has been introduced. The new `event_handler_hook_use` and `loop_hook_use` functions will only allow one copy of the hook. The `event_handler_hook_append` and `loop_hook_append` functions will, on the other hand, just append the hooks, and not care about protection. The `event_handler_hook_add` and `loop_hook_add` functions are gone, but for the time being, they are aliases to the `_use` functions, until all plugins have been updated, and the aliases can be removed. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
#define loop_hook_add loop_hook_use