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.

Sign up for GitHub

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

Jump to bottom

Store details of the EEPROM layout in both flash and EEPROM so that we can be smarter about reinitialization of EEPROM after an incompatible firmware update #1451

Open
obra opened this issue Nov 23, 2024 · 0 comments
Open

Store details of the EEPROM layout in both flash and EEPROM so that we can be smarter about reinitialization of EEPROM after an incompatible firmware update #1451

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

Comments

@obra
Copy link
Member

obra commented Nov 23, 2024

Right now, flashing a firmware update that changes the eeprom layout onto a device results in scrambled keymaps. That's...less than ideal. It'd be better to wipe the EEPROM (or entirely disregard it) in cases like that.

Longer term, on devices with more storage, we should move to a configuration system that is not based on exact indexes into the EEPROM.
@obra obra added the design-change Proposals that incur potentially breaking design changes label Nov 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
design-change Proposals that incur potentially breaking design changes
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@obra