fix(windows): reduce blast radius of sft-arrow workaround #414
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit makes changes to the blast radius of the workaround for issue #138: > Shift and arrows interact weirdly on a layer Discovered in this issue was a problem where activating shift on keys other than the physical shift keys, and then also pressing arrow keys, caused stuck-shift behaviour. The fault is, as is typical, Windows' weird behaviour. The workaround added was to release all shift key states if a single shift key state was found to no longer exist, when comparing the previous keyberon state to the current one. In some cases, this release of shift causes an earlier release of shift than is desired, because some other key activated shift. This commit reduces the blast radius of the shift state releases to only states with the physical lsft key. In hindsight, Windows' weird behaviour only would have affected the physical lsft key's coordinate anyway, so this is a good change to make. In addition, this issue only affects the LLHOOK mechanism and not Interception, so the code is conditionally compiled out for the Interception driver as well.
jtroo
changed the title
jtroo
changed the title
jtroo
force-pushed
the
reduce-lsft-workaround-blast-radius
branch
from
dd17391
to
25593de
Compare
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 commit makes changes to the blast radius of the workaround for issue #138:
Discovered in this issue was a problem where activating shift on keys other than the physical shift keys, and then also pressing arrow keys, caused stuck-shift behaviour. The fault is, as is typical, Windows' weird behaviour. The workaround added was to release all shift key states if a single shift key state was found to no longer exist, when comparing the previous keyberon state to the current one.
In some cases, this release of shift causes an earlier release of shift than is desired, because some other key activated shift. This commit reduces the blast radius of the shift state releases to only states with the physical lsft key. In hindsight, Windows' weird behaviour only would have affected the physical lsft key's coordinate anyway, so this is a good change to make. In addition, this issue only affects the LLHOOK mechanism and not Interception, so the code is conditionally compiled out for the Interception driver as well.
Fixes #346