Repository navigation
Conversation
pgaskin
force-pushed
the
virtual-input-fixes
branch
3 times, most recently
from
October 10, 2026 05:12
32c038f to
e4701e7
Compare
If a virtual keyboard uses the seat's keymap, modifier state is shared with other input devices, and resetting it to zero may clear modifiers set by other devices (e.g., numlock, capslock). This affects, e.g., fcitx, which destroys its virtual keyboard when it loses focus, which previously would have reset the modifiers, including ones set through other devices. The compositor is now responsible for choosing if/how to reconcile the modifier state on virtual keyboard removal (e.g., by tracking the bits set by it).
pgaskin
force-pushed
the
virtual-input-fixes
branch
from
October 10, 2026 05:37
e4701e7 to
8f5bb53
Compare
pgaskin
changed the title
pgaskin
marked this pull request as ready for review
October 10, 2026 05:38
Contributor
Author
YaLTeR
reviewed
Oct 10, 2026
IMEs like fcitx which grab the keyboard may pass through unhandled keys through a virtual keyboard, which would previously result in a busy loop. By adding a client/source getter to the virtual keyboard and a function to forward input events bypassing the grab, this situation can be avoided. Assigning a KeyboardSource to each virtual keyboard also fixes fcitx dropping held modifiers also held by other keyboards on deactivation. This happens since fcitx echoes every key it receives through its virtual keyboard, and destroying that keyboard on focus-out causes key releases to be sent for the keys still down, which used to release the physical keyboard's keys too. Keys are now released by the last holder rather than the first. Shortcuts across physical and virtual devices still work.
pgaskin
force-pushed
the
virtual-input-fixes
branch
from
October 10, 2026 08:46
8f5bb53 to
8c09dac
Compare
YaLTeR
approved these changes
Oct 10, 2026
YaLTeR
left a comment
YaLTeR
left a comment
Collaborator
There was a problem hiding this comment.
Seems ok; someone else please check.
Also insert the usual smithay needs to have stacked grabs etc, but with the current system this will do I guess. I think it matches the behavior pre virtual keyboard rework?
Contributor
Author
More or less, depending on how the compositor chooses to wire it up. |
This branch has not been deployed
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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
Mostly edge cases around clients with keyboard grabs also sending virtual keyboard events, e.g. fcitx.
niri-wm/niri#4548 (comment)
Checklist