Add new function for encode module

[KeychronMacro]

Improved encoder

Description

• Improve the encoder and make it perform better, specifcally add a function called "encoder_insert_state", and will be called in pal set line event callback function when we turn the knob every time.

Types of Changes

• [x] Core
• [ ] Bugfix
• [x] New feature
• [ ] Enhancement/optimization
• [ ] Keyboard (addition or update)
• [ ] Keymap/layout/userspace (addition or update)
• [ ] Documentation

Issues Fixed or Closed by This PR

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.
• [x] I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[zvecr]

Core changes should be separate to keyboard changes.

[lokher]

Core changes should be separate to keyboard changes.

We added a new function to encoder.h and encoder.c, which is only invoked by Q2, and it won't break anything, why do we need to separate it? It's kinda wierd if we just add a single function, maybe someone would ask how to use it to fix this issue.

[zvecr]

Because that is the process we ask people to follow, as it allows us manage the project easier.

By default core changes also have to go via develop, so i have updated the merge target (this is within the PR checklist).

[FWest98]

This change no longer works properly - it causes the rotary encoder to stop functioning altogether. This is due to the new if-condition at https://github.com/qmk/qmk_firmware/blob/master/quantum/encoder.c#L197, introduced in #16068. It prevents the encoder from triggering an action when this code path does not detect a state change - this will almost always be the case since encoder_insert_state already updates this state. The best solution I found to this issue is to introduce an additional condition that will trigger the update function to be called after the external update. See: https://github.com/FWest98/OS-QMK_Firmware/commit/95fbce9628191522bf9acb07808812b5c5463152#diff-c8e0671af976b0c896b651211e9605562985027873e5ef0d8a51a74c17aa8a6e

[github-actions[bot]]

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.

[github-actions[bot]]

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.

[spacecakes]

Any updates on this? Is it still relevant? @lokher

[github-actions[bot]]

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.

[github-actions[bot]]

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.

[tzarc]

We'll be moving towards a decoupled model with ENCODER_DRIVER = xxxx instead of continuing here.