Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redesign EEPROM Keymap storage to be more extensible and flexible #1419

Open
obra opened this issue Apr 30, 2024 · 0 comments
Open

Redesign EEPROM Keymap storage to be more extensible and flexible #1419

obra opened this issue Apr 30, 2024 · 0 comments
Labels
design-change Proposals that incur potentially breaking design changes

Comments

@obra
Copy link
Member

obra commented Apr 30, 2024

[this first somewhat sketchy description is extracted from notes on @hupfdule's PR #1340 ]

We need is some way to represent the data for what a key in the keymap does on long press in EEPROM, coupled with a way to mark a key on a given layer as having long-press behavior that needs to be resolved by the longpress plugin.

Right now, eeprom keymaps are 16 bits per key per layer (

void EEPROMKeymap::updateKey(uint16_t base_pos, Key key) {
) - 8 bits for the primary keycode and 8 bits for flags describing modifications to that keycode:
// Constant flags values

Plugins can define ranges of keycodes they use for their own specialized behavior, but those ranges are somewhat limited. https://github.com/keyboardio/Kaleidoscope/blob/master/plugins/Kaleidoscope-Ranges/src/Kaleidoscope-Ranges.h#L83

So we could set up, say, 32 "longpress" keys that get handed off to the longpress plugin for evaluation, sort of like how we do Dynamic Macros: https://github.com/keyboardio/Kaleidoscope/blob/master/plugins/Kaleidoscope-DynamicMacros/src/kaleidoscope/plugin/DynamicMacros.cpp

But that's not a great user experience and feels very...limiting.

It feels sort of like it might be time to think about redesigning how we store keymaps in EEPROM to make them more extensible. But that's not a small undertaking.

I'd dearly love to be able to support full configuration of LongPress, QuKeys, Chords, and all the rest in Chrysalis.

@obra obra added the design-change Proposals that incur potentially breaking design changes label Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design-change Proposals that incur potentially breaking design changes
Projects
None yet
Development

No branches or pull requests

1 participant