qmk_firmware
qmk_firmware copied to clipboard
Sofle Choc hardware variant
Description
- New hardware variant of the Sofle keyboard (
keyboards/sofle/choc
) - New default keymap (
keyboards/sofle/keymaps/choc_default
) - New Via keymap (
keyboards/sofle/keymaps/choc_via
)
Types of Changes
- [ ] Core
- [ ] Bugfix
- [ ] New feature
- [ ] Enhancement/optimization
- [x] Keyboard (addition or update)
- [ ] Keymap/layout/userspace (addition or update)
- [ ] Documentation
Checklist
- [x] My code follows the code style of this project: C, Python
- [x] I have read the PR Checklist document and have made the appropriate changes.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the CONTRIBUTING document.
- [ ] I have added tests to cover my changes.
- [ ] I have tested the changes and verified that they work and don't break anything (as well as I can manage).
@drashna thank you for the review and detailed comments. Applied all of them to this PR. Ready for review again
Does this version still have the bug where the slave half doesn't synch RGB state from master?
Does this version still have the bug where the slave half doesn't synch RGB state from master?
Fixed thanks to @derpus-potatus and @at669
Does this version still have the bug where the slave half doesn't synch RGB state from master?
Fixed thanks to @derpus-potatus and @at669
AWESOME! Just tried it and it works great! What was the fix out of curiosity? (And my sanity since I spent the last couple of hours on trying to fix that myself)
@B-1P details here: https://github.com/josefadamcik/SofleKeyboard/issues/124#issuecomment-1025069293
New keymaps should be moved under the choc directory, as they won't be automatically compiled by CI otherwise.
Thanks @fauxpark, moved new keymaps under choc:
keyboards/sofle/choc/keymaps/default
keyboards/sofle/choc/keymaps/via
thanks! is there anything left to get this approved and merged?
Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug
, awaiting review
, breaking_change
, in progress
, or on hold
to prevent the issue from being re-flagged.
What's the status on this?
Any chance you can get @drashna's suggestions added and can proceed with merging this?
Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug
, awaiting review
, breaking_change
, in progress
, or on hold
to prevent the issue from being re-flagged.
Can this be merged?
There are still pending reviews.
I think all feedback has been addressed
Sorry for the review requests, didn't understand how this repo was setup.
@mekeor had requested changes and I've implemented
Anyone assigned to review this?
Any news on this PR?
@fauxpark Feedback applied, thanks!
Ideally, this should be in keyboards/sofle/choc, and not a separate folder.
@drashna An earlier review (https://github.com/qmk/qmk_firmware/pull/16736#discussion_r844724538) suggested moving it out because this hardware is incompatible with with the top-level sofle keyboard.
There is an issue (#16829) and PR (#17979) to reorganize the sofle folder to better support hardware variations.
Let me know how best to proceed
Ah, no worries then. I missed that.
@drashna what is the next step for this PR?
Whats the next step @fauxpark
@drashna feedback applied. Credit to @duese for the work, thanks!
Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug
, awaiting review
, breaking_change
, in progress
, or on hold
to prevent the issue from being re-flagged.
Anything pending?
Anything pending?
We're waiting for a final approval of any maintainer. Unfortunately I have no idea how to accelerate this process somehow. This MR is now over a year old. Must be frustrating for Brian not seeing his variant merged.
As this has now passed a breaking changes merge (again) I must be the bearer of frustrating news- the last breaking changes require that a good deal of config.h contents be translated into info.json.
I appreciate this has been open a long time, and a few weeks ago may well have been mergeable, but with the latest changes this needs to be brought up to date again.
Thanks for the update. I am happy to update this branch if a repo maintainer is up for sponsoring this PR or there is a concrete path to merging. Let me know! Thanks, Brian
Thanks for the feedback
I am happy to update this PR if there is a concrete path to merging. My concern is spending time on this only to have the PR linger and fall behind main again. For context, this PR has had roughly 15 requests for changes over 15 months. I've completed them all.
If the repo owners can't provide more assurances, I understand. This is a volunteer project and am grateful for the project as-is. If that is the case, lets close this PR and save everyone time.