feat: better handling of Windows LLHOOK stuck keys #531
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
|
Other than the compilation failure, this doesn't quite work. As an optimization, in most cases kanata can go idle even while keys are still pressed, so the current 65s check doesn't work properly. |
There are two changes in this commit. 1) Always live reload after ~1s. After 1 second if live reload is still not done, there might be a key in a stuck state. One known instance where this happens is Win+L to lock the screen when on Windows and using the LLHOOK mechanism. The release of Win and L keys will not be caught by the kanata process when on the lock screen. However, the OS knows that these keys have released - only the kanata state is wrong. And since kanata has a key in a stuck state, without this 1s fallback, live reload would never activate. Having this fallback allows live reload to happen which resets the kanata states. 2) Clear normal states (not fake key) after blocking for a while This code only runs in the LLHOOK Windows version. The reason for this existing is the same as in 1). The main motivator is the Win+L example. The thought is that after locking their screen, the user will probably go away for a while. The software can detect that the zero user inputs were input for extended period of time and assume that keys got stuck.
jtroo
force-pushed
the
live-reload-1s-bypass
branch
from
e8f55d6
to
abb6c3f
Compare
|
Came up with a different solution that probably works as expected. |
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.
There are two changes in this commit.
After 1 second if live reload is still not done, there might be a key in a stuck state. One known instance where this happens is Win+L to lock the screen when on Windows and using the LLHOOK mechanism. The release of Win and L keys will not be caught by the kanata process when on the lock screen. However, the OS knows that these keys have released - only the kanata state is wrong. And since kanata has a key in a stuck state, without this 1s fallback, live reload would never activate. Having this fallback allows live reload to happen which resets the kanata states.
This code only runs in the LLHOOK Windows version. The reason for this existing is the same as in 1). The main motivator is the Win+L example. The thought is that after locking their screen, the user will probably go away for a while. The software can detect the abnormality of zero user inputs for an extended period of time while still not being idle and assume that keys got stuck.