It might be helpful to add a custom handler for key input so that a user can have custom actions that can't be done by existing keycodes. QMK does this with process_record_user.
This could probably be implemented the way QMK does it by having the user supply an optional function pointer with the signature KeyAction -> bool that would be run before the match statement in Keyboard::process_key_change. The returned boolean would then control whether the normal action handler is run after the custom handler. This would maybe also require exposing other fields or channels so that the function could add keycodes to be processed or trigger other parts of the firmware.
It might be helpful to add a custom handler for key input so that a user can have custom actions that can't be done by existing keycodes. QMK does this with process_record_user.
This could probably be implemented the way QMK does it by having the user supply an optional function pointer with the signature
KeyAction -> bool
that would be run before the match statement inKeyboard::process_key_change
. The returned boolean would then control whether the normal action handler is run after the custom handler. This would maybe also require exposing other fields or channels so that the function could add keycodes to be processed or trigger other parts of the firmware.