-
-
Notifications
You must be signed in to change notification settings - Fork 40.4k
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
Refactor Leopold keyboards and add support for new FC980C controller #22260
Conversation
4eb2823
to
ef8305d
Compare
Also rewrite bare links in READMEs.
Adds I2C error handling. Fixes a bug where the I2C address was not shifted left by one bit, which is a quirky requirement of the QMK i2c_master API.
While the AD5258 has its own EEPROM store, we try not to touch it prevent overwriting the factory value, instead store and load the value from QMK's EEPROM.
ef8305d
to
13fe732
Compare
Is there anything else that needs to be changed/updated here? Shall I spin out the bug fix into a separate PR (in light of the breaking changes timeline)? Otherwise the upcoming cycle will have broken AD5258 support for the FC980C/FC660C in master, though I imagine the impact will be pretty low. Apologies for poking. |
Co-authored-by: Drashna Jaelre <drashna@live.com>
Thank you for your contribution! |
Thank you for your contribution! |
Description
This supersedes #19734, which I unfortunately forgot about. I want to apologize to the original reviewers that graciously offered their time reviewing the original PR.
The ultimate goal of this is adding support for a new FC980C controller, but first I have to move the existing Leopold boards under a common directory and de-duplicate driver code. The steps have been broken out into individual commits.
Summary:
leopold/
hasu
to make room for the new controller configsi2c_master
API has a quirk where it requires a I2C address to be shifted to the left which the old driver didn't haveI'm a bit unsure about the includes. It all compiles, but not sure about the paths. The build systems seems to mush the paths together, for example both
#include "ad5258.h"
and#include "../../ad5258.h"
seem to work so I'm not sure what's preferred here.This incorporates all the feedback from the original PR except for the includes since the structure changed slightly, so I'm not sure how much of it is still relevant.
This will be affected by #22253, so I'll update once that is merged.DoneTypes of Changes
Checklist