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

Rework encoders to enable asymmetric split keyboards #12090

Merged
merged 19 commits into from
Nov 20, 2021

Conversation

BalzGuenat
Copy link
Contributor

@BalzGuenat BalzGuenat commented Mar 2, 2021

Description

This allows asymmetric split keyboards to have a different number of encoders on each half.
Previously, the code assumed an equal number of encoders, even if they were wired differently.

This should be fully backwards compatible.

Types of Changes

  • Core
  • Enhancement/optimization
  • Documentation

Issues Fixed or Closed by This PR

Checklist

  • My code follows the code style of this project: C, Python
  • 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.
  • 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).

I will fix the code style while I wait for comments. I would appreciate some help with testing this, as I only know how to test this on hardware.

P.S.: Not sure if this counts as a core PR...

@BalzGuenat
Copy link
Contributor Author

Heads up that these changes will almost certainly conflict with those in #11706. I'd be willing to resolve those conflicts when they arise.

@BalzGuenat
Copy link
Contributor Author

So I've just spent a few hours unsuccessfully trying to get even a single unit test to compile. I've hit only brick walls. If anyone wants to help with that over here, I would be thankful.

That said, I've removed all efforts towards unit tests from this PR so that it's clean and ready to merge.

@BalzGuenat BalzGuenat marked this pull request as draft March 4, 2021 22:52
@BalzGuenat BalzGuenat marked this pull request as ready for review March 4, 2021 23:13
@BalzGuenat
Copy link
Contributor Author

BalzGuenat commented Mar 4, 2021

Two users/boards implement their own transport.c:

I'm leaving it to @drashna to adopt the changes I made to transport.c into those files.

@BalzGuenat
Copy link
Contributor Author

I have finally managed to add some unit tests! Thanks a bunch to @ThreeFx for the help!

@drashna
Copy link
Member

drashna commented Mar 7, 2021

Two users/boards implement their own transport.c:

I'm leaving it to @drashna to adopt the changes I made to transport.c into those files.

Those are all mine, so no worries. And I plan on deprecating them in the near future, as well.

I have finally managed to add some unit tests! Thanks a bunch to @ThreeFx for the help!

Huzzah!

Comment on lines +56 to +58
#define ENCODERS_PAD_A { }
#define ENCODERS_PAD_B { }
#define ENCODER_RESOLUTIONS { }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be worth removing this.

In the encoder.c file, you could add:

#ifndef ENCODERS_PAD_A
#    define ENCODERS_PAD_A {  }
#endif

Or the like.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was a bit worried about making things confusing. Leaving out the left side would have very different effect from leaving out the right side. Leave out the _RIGHT pads, the pads get mirrored and you get encoders on both sides. But leave out the "normal" (aka. left) pads and you only get encoders on right.

It would also mean that a board with encoders on only left would look different from a board with encoders only on right:

// only right
#define ENCODERS_PAD_A_RIGHT { X }
#define ENCODERS_PAD_A_RIGHT { Y }
// only left
#define ENCODERS_PAD_A { X }
#define ENCODERS_PAD_A { Y }
#define ENCODERS_PAD_A_RIGHT {  }
#define ENCODERS_PAD_A_RIGHT {  }

Waddaya think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I'd prefer to explicitly require both sides in definitions, if an asymmetrical encoder setup is defined.
So you could do the #ifdef, but I'm not sure it's the most readable/understandable/maintainable.

So yeah, my vote would be both:

// only right
#define ENCODERS_PAD_A { }
#define ENCODERS_PAD_A { }
#define ENCODERS_PAD_A_RIGHT { X }
#define ENCODERS_PAD_A_RIGHT { Y }
// only left
#define ENCODERS_PAD_A { X }
#define ENCODERS_PAD_A { Y }
#define ENCODERS_PAD_A_RIGHT { }
#define ENCODERS_PAD_A_RIGHT { }

@BalzGuenat
Copy link
Contributor Author

It's been a while. Anything more I can do to get this merged?

@drashna drashna requested a review from a team April 9, 2021 21:28
@stale
Copy link

stale bot commented Jul 10, 2021

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 awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

@stale
Copy link

stale bot commented Aug 21, 2021

Thank you for your contribution!
This pull request has been automatically closed because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, or re-open when it's ready.

@stale stale bot closed this Aug 21, 2021
# Conflicts:
#	build_test.mk
#	quantum/encoder.c
#	quantum/split_common/transport.c
#	testlist.mk
@BalzGuenat
Copy link
Contributor Author

After months, I have updated my branch today. Could this please be reopened?

Copy link
Member

@tzarc tzarc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only real request for change is to make sure all the C/CPP/H files have GPL2+ copyright headers.

Comment on lines +56 to +58
#define ENCODERS_PAD_A { }
#define ENCODERS_PAD_B { }
#define ENCODER_RESOLUTIONS { }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I'd prefer to explicitly require both sides in definitions, if an asymmetrical encoder setup is defined.
So you could do the #ifdef, but I'm not sure it's the most readable/understandable/maintainable.

So yeah, my vote would be both:

// only right
#define ENCODERS_PAD_A { }
#define ENCODERS_PAD_A { }
#define ENCODERS_PAD_A_RIGHT { X }
#define ENCODERS_PAD_A_RIGHT { Y }
// only left
#define ENCODERS_PAD_A { X }
#define ENCODERS_PAD_A { Y }
#define ENCODERS_PAD_A_RIGHT { }
#define ENCODERS_PAD_A_RIGHT { }

@BalzGuenat BalzGuenat requested a review from tzarc November 3, 2021 16:35
@tzarc tzarc requested review from a team and drashna November 17, 2021 21:09
@drashna
Copy link
Member

drashna commented Nov 19, 2021

have a couple of merge conflicts.

@tzarc
Copy link
Member

tzarc commented Nov 19, 2021

Fixed the merge conflicts, however tests are currently failing. @BalzGuenat would you mind investigating with a make test:all?

@tzarc
Copy link
Member

tzarc commented Nov 20, 2021

Merged with develop to ensure the unit test workflow executes on CI.

@BalzGuenat
Copy link
Contributor Author

Fixed the tests. The callback override didn't work anymore since the signature changed in #12805.

@drashna drashna merged commit 32215d5 into qmk:develop Nov 20, 2021
@drashna
Copy link
Member

drashna commented Nov 20, 2021

Unfortunately, this looks like it broke a bunch of the encoder boards with:

quantum/split_common/transport.h:74:37: error: expected ‘)’ before ‘]’ token                                                                              
     uint8_t state[NUMBER_OF_ENCODERS];

And other errors.

drashna added a commit that referenced this pull request Nov 20, 2021
@BalzGuenat BalzGuenat mentioned this pull request Nov 20, 2021
14 tasks
@drashna
Copy link
Member

drashna commented Nov 27, 2021

Just a heads up, this seems to have caused a bug during initialization.

Eg, it spams encoder updates until the board has normalized.

drashna added a commit to drashna/qmk_firmware that referenced this pull request Nov 27, 2021
tzarc pushed a commit that referenced this pull request Nov 27, 2021
* Revert "fix broken macro in transport.h (#15239)"

This reverts commit 06f18e2.

* Revert "Rework encoders to enable asymmetric split keyboards (#12090)"

This reverts commit 32215d5.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants