The KWindowSystem change 32526718eae99ccb594360627586eebdf793372b caused
a regression in KWin as Qt::Enter on keypad is no longer enter, but enter
with modifier mask. For all other modifiers it was never a problem that
the KKeyServer method also returned modifiers as it could not read the
X modifiers anyway.
As KWin has full knowledge about the modifiers through Xkb it does not
need the modifier mapped into the Qt::Key.
This fixes the failing TestWindowSelection autotest which started to fail
due to the change in KWindowSystem.
Summary:
If the keymap cannot be created a few pointers in Xkb are null.
We should make sure to not call any xkbcommon functions on those
null pointers and instead use proper fallbacks.
This change introduces fixes for a few usages, but it's not unlikely
that there are more cases.
BUG: 381210
FIXED-IN: 5.10.3
Test Plan:
Autotest added for the condition of the bug, which does
not crash any more. Just starting the test found a few more crash
cases.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6260
Summary:
Consider the case that capslock gets pressed and released.
In the case of Weston we have a sequence of:
1. Key press event
2. Modifier changed event
3. Key release event
4. Modifier changed event
KWin however used to send the events in the following sequence:
1. Modifier changed event (on key press)
2. Key press event
3. Modifier changed event (on key release)
4. Key release event
It looks like Xwayland is not able to properly process the sequence
sent by KWin. And in fact KWin's sequence is wrong as it sends a state
which does not match. We report that the caps lock is pressed in the
modifiers prior to the application getting informed about the key press
of caps lock.
This change aligns KWin's implementation to the behavior of Weston. The
main difference is that when modifiers change Xkb internally caches the
serialized modifier states. And KeyboardInputRedirection just forwards
the modifiers to KWayland::Server::SeatInterface once the processing has
finished. SeatInterface ignores the forwarding if no states changes, so
it is fine to do it that way.
BUG: 377155
Test Plan:
Not yet tested with an affected Xwayland as I only have 1.18 and the
problem started with 1.19. But verified the sequence of events with WAYLAND_DEBUG
and caps lock stil working in QtWayland clients and Xwayland 1.18
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5452
