Summary:
This change brings improved num lock support to KWin. The modifier state
is read and also mapped to Qt::KeyboardModifiers. Furthermore the input
config is read and the NumLock key is evaluated. If the requested state
does not match the current num lock state the state is swapped.
BUG: 375708
FIXED-IN: 5.15
Test Plan: New unit test added, no manual test due to lack of hardware
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16428
Summary:
As kwin_wayland can have the CAP_SYS_NICE capability, libxkbcommon does not
read environment variables (see secure_getenv).
So process them here, in the same way xkb_context_sanitize_rule_names would.
BUG: 388249
Test Plan: kwin_wayland has the capability set, keyboard layout is applied correctly.
Reviewers: #plasma, graesslin
Subscribers: kwin, plasma-devel, #kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9873
Summary:
This is needed in virtual keyboard and also used KKeyServer so far. With
this change it is moved to new API provided in Xkb. The new translation
map is now also used for the direction from Qt::Key +
Qt::KeyboardModifier to xkb_keysym_t.
New implementation is supported by a new test case covering the same
combinations as in the existing direction.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7356
Summary:
Turn Xkb into a QObject
Reduced dependencies on other classes and allows to emit signal directly
instead of emitting a signal on another class.
Dependency inject KWayland::Server::SeatInterface into Xkb
No need to depend on WaylandServer from within Xkb.
[autotests] Add test case for Xkb::toQtKey
Tests all key codes KKeyServer is able to map to Qt.
Migrate Xkb::toQtKey away from KKeyServer
The regression in kwindowsystem in
32526718eae99ccb594360627586eebdf793372b showed once more that it's time
to migrate the xkb keysym to Qt::Key mapping away from KKeyServer. The
main problem with KKeyServer is that it's made for X11 and we don't have
X11 here. This causes warnings printed at runtime and the code only
works by accident at all because KKeyServer fails to initialise
modifiers. That is normally KKeyServer would include the modifiers, but
that is nothing we are interested in for mapping xkb keysyms to Qt::Key.
So to address this, KWin now implements the mapping itself. It's based
on the implementation in KKeyServer, but also improved by providing
faster xkb to Qt conversion (which matters for KWin more than the other
direction).
Long term plan is to extend this so that also on X11 it can be used.
Then it should be split out and be used in KKeyServer as a replacement
for the current implementation which could support both X11 and Wayland.
Test Plan:
New test case added which covers all keysyms supported by
existing KKeyserver mapping
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7336
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
