Fix encoder breakage with 4 or more encoders #23595
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
The encoder support was broken in various ways when having 4 or more encoders on any keyboard side (or, more precisely, when
MAX_QUEUED_ENCODER_EVENTS
was not a power of 2, which happened whenNUM_ENCODERS_MAX_PER_SIDE
increased above 3, unlessMAX_QUEUED_ENCODER_EVENTS
was set directly). In particular, with 4 encoders the encoder rotation did not have any effect.The problem was caused by
encoder_queue_full_advanced()
always returningtrue
even when the queue was not actually full, which caused all encoder events to be dropped. The underlying reason was that(events->tail - 1) % MAX_QUEUED_ENCODER_EVENTS
did not calculate what the rest of code expected whenevents->tail
was 0, except whenMAX_QUEUED_ENCODER_EVENTS
happened to be a power of 2, so the code seemed to work when the number of encoders was less than 4 (in that caseMAX_QUEUED_ENCODER_EVENTS
was set to 4), but broke when the number of encoders was 4 or more. With 4 encoders the code ended up calculating0xffff % 5U
(or0xffffffff % 5U
on 32-bit platforms), which ended up being 0, so the initial state with an empty queue was mistakenly detected as full. But withMAX_QUEUED_ENCODER_EVENTS
= 4 the result of0xffff % 4U
in the bad case happened to be what was expected, therefore the bug could not be noticed.Fix the queue full check to avoid negative numbers in calculations, so that the modulo operations would work as expected.
Types of Changes
Issues Fixed or Closed by This PR
Checklist