Fix KeyAddrEventQueue::shouldAbort()
(qukeys getting stuck)
#1321
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.
This fixes a problem that was causing key events to get dropped in some cases when the event id rolled over from positive to negative values while a plugin had events queued spanning both sides of the overflow. This would generally result in event
127
getting dropped. If the dropped event was a keyswitch toggling on, the key would be unresponsive. If it was a key release, the key would get "stuck on".The problem was that the 8-bit integer
KeyEventId
values were getting promoted to 16-bit integers when computing the difference between the event being flushed from the queue and the event at the head of the queue. The resulting 16-bit value (-128 - 127
) would be negative, whereas its 8-bit counterpart would be positive, resulting in a false positive return value fromshouldAbort()
. The fix is to convert the difference back to an 8-bit integer before doing the comparison with zero.I've included a testcase that fails without the fix.