-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modifiers can erroneously end up perma-set #583
Labels
Milestone
Comments
Jules-Bertholet
added a commit
to Jules-Bertholet/libxkbcommon
that referenced
this issue
Jan 8, 2025
Jules-Bertholet
added a commit
to Jules-Bertholet/libxkbcommon
that referenced
this issue
Jan 8, 2025
It seems this bug is present since at least xkbcommon 1.0. We would have detected before if we supported StickyKeys control (see #596). |
wismill
added a commit
to Jules-Bertholet/libxkbcommon
that referenced
this issue
Jan 16, 2025
The modifiers filters should ensure minimal interaction between them, but currently the Latch mod filters are overzealous and mess with the mods from other filters set to be cleared, resulting in some modifiers permanently set. Fixed by clearing mods properly with `OR` rather than direct setting of `state::clear_mods`. While we are at it, `state::set_mods` should be `OR`ed as well. This should not have any impact for now, but this is more future-proof. Fixes xkbcommon#583 Co-authored-by: Jules Bertholet <[email protected]> Co-authored-by: Pierre Le Marre <[email protected]>
wismill
added a commit
to Jules-Bertholet/libxkbcommon
that referenced
this issue
Jan 16, 2025
The modifiers filters should ensure minimal interaction between them, but currently the Latch mod filters are overzealous and mess with the mods from other filters set to be cleared, resulting in some modifiers permanently set. Fixed by clearing mods properly with `OR` rather than direct setting of `state::clear_mods`. While we are at it, `state::set_mods` should be `OR`ed as well. This should not have any impact for now, but this is more future-proof. Fixes xkbcommon#583 Co-authored-by: Jules Bertholet <[email protected]> Co-authored-by: Pierre Le Marre <[email protected]>
wismill
added a commit
that referenced
this issue
Jan 16, 2025
The modifiers filters should ensure minimal interaction between them, but currently the Latch mod filters are overzealous and mess with the mods from other filters set to be cleared, resulting in some modifiers permanently set. Fixed by clearing mods properly with `OR` rather than direct setting of `state::clear_mods`. While we are at it, `state::set_mods` should be `OR`ed as well. This should not have any impact for now, but this is more future-proof. Fixes #583 Co-authored-by: Jules Bertholet <[email protected]> Co-authored-by: Pierre Le Marre <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider the following symbols file (reduced from a real-world example):
When used along with the standard
xkeyboard-config
data, under currentxkbcommon
, with the following sequence of keypresses:<LCTL>
<RALT>
<LCTL>
<RALT>
<AB01>
(this should unlatchLevelThree
)LevelThree
(Mod5
) ends up permanently set, with no way to clear it, making the keyboard unusable.The text was updated successfully, but these errors were encountered: