Summary:
When triggering global shortcuts we are more interested in the hold
keys than the currently active modifiers. E.g. capslock should not
be seen as "shift is hold". Similar we need to remove consumed
modifiers. Shift+5 is % and not Shift+% - the shift modifier is
consumed and needs to be removed from shortcut evaluation.
To support this we need to have the actual state directly from
xkbcommon. Thus a new method is added which exposes the modifiers
relevant for global shortcut matching. In addition on every key press
all consumed modifiers are calculated and kept so that they can be
used for shortcut matching.
In addition a workaround is added for Backtab. Similar workaround
exists in kglobalaccel for X11. The problem is that our shortcuts are
stored incorrectly: Shift+Tab instead of Backtab. Thus a mapping back
is required. To make everything worse KWin registers the wrong key
sequence "Alt+Shift+Backtab" which doesn't make any sense and is
broken on X11 at least.
The workaround supports both special cases. The one for Backtab should
be turned into Shift+Tab and also KWin's special case of adding shift
to backtab.
CCBUG: 368581
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2768
Summary:
The Xkb class now creates a compose key table and a state object and
feeds all key presses through the compose state machine.
Xkb now tracks the latest keysym which is provided through new method
currentKeysym. This is now used when creating a QKeyEvent instead of
passing the key code to the xkb state. With that the keysym can also
be updated through the compose state system.
This only affects KWin internal usage where text is composed, e.g. the
present windows effect filter. Wayland clients do not gain compose key
support, though.
Minimum xkbcommon version raised to 0.5 as compose key support is new
in that version.
Test Plan: Enabled compose key support in keymap and verified through DebugConsole
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2622
At the same time the xinput2 integration is split out of X11Cursor
and made a standalone part of the platform plugin. XInput integration
is nowadays not only used by the cursor position polling, but also
for modifier only shortcuts.
By splitting it out the modifier shortcuts start to work also when
one doesn't have anything requesting a mouse position polling.
This also simplifies the conditional builds: xinput integration is
only included if we have support for it at compile time without having
to have many ifdefs in the cursor implementation. For the inclusion of
cursor in the kcmkwin this also removes all the ifdefs.
The key events are only requested if we have xinput 2.1. Otherwise we
would not get all raw events if the input device gets grabbed.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2473
Summary:
If caps lock is on the shift key should not trigger. Similar pressing
caps lock should neither on activation press nor on deactivation press
trigger the shortcut. Related to that are latched modifiers aka sticky
modifiers: if the modifier is still on after releasing the key the
shortcut should not trigger. We must assume the user wanted to use the
modifier to activate the modifier, not to activate the shortcut.
This change ensures that we don't track for modifier only shortcuts if
a modifier is active before press or after release.
The added test case demonstrates for caps lock, latched modifiers is
currently still untested. (Needs a way to mock it).
Test Plan: See test case for caps lock.
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2467
Summary:
For XWayland windows the window might be activated before the Wayland
Surface is set for it. Thus the keyboard focus is not passed to the
window. Only on the next activate after the window got created the
window got keyboard focus.
This change addresses this problem by emitting a signal from Toplevel
when the surface changes. The KeyboardInput listens to this signal
for the active client and updates keyboard focus again if the surface
changes. Thus keyboard focus is properly passed to XWayland windows.
Test Plan:
Test case which creates an X11 window is adjusted to verify
the condition.
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2009
Summary:
The signals emitted by LibInput::Connection carry the Device for which
the input event was received. This Device is passed to the input handlers.
Custom event classes are added which extend QMouseEvent, QKeyEvent and
QWheelEvent respectively and expose the Device. The Device is only passed
around as a forward declared pointer, so even if compiled without libinput
support, it should still compile.
Event handlers which need to get access to the Device can now just cast
the event pointer to the custom class and access it. This can be used in
future to handle device specific key codes, etc.
As we don't have a proper event classes for touch events the event
handlers do not yet have access to the Device. Here the internal API
needs to be adjusted in future.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1667
KWin starts to track which is the current layout and in case it changes
notifies the org.kde.osdService about the change through DBus. KWin has
a better knowledge about changes than the KeyboardDaemon could have, so
it's better to do in KWin. E.g. KWin can also notice changes not
triggered by the global shortcut, but by the keymap itself.
KWin registers/steals the shortcut of the "KDE Keyboard Layout Switcher"
and binds it to a new method which actually switches the layout.
The actual switcher from which the shortcut is stolen should only be a
representation on Wayland. Though how to do this is a problem for the
future. Only the active window is notified about layout changes and the
plasmoid will never get the event in time. This is of course a minor
problem compared to the fact that the KeyboardDaemon is absolutely X11
dependent.
This is the start for adding proper support for keyboard layouts. If
we have a configuration in kxkbrc the keymap is generated from that
information. This allows to have different layouts and also layout
switching is working (though not yet passed to Wayland clients properly).
Not yet working is the global shortcut for layout switching and
reconfiguring the layouts.
As a Wayland server KWin does not have to emit additional key repeat
events (unlike X11). The clients are responsible for handling this based
on the provided key repeat information.
Internally KWin needs key repeat, though. E.g. the effects need key
repeat (filtering in Present Windows), window moving by keyboard needs
repeat, etc. etc.
This change introduces the internal key repeat. For each key press a
QTimer is started which gets canceled again on the key release. If the
timer fires it invoked processKey with a new KeyboardKeyAutoRepeat state.
This is handled just like a KeyPress, but states are not updated and
the QKeyEvent has autorepeat set to true.
The event filters check for the autorepeat state and filter the event
out if they are not interested in it. E.g. the filters passing the event
to the Wayland client need to filter it out.
Currently auto-repeat is bound to using libinput. This needs to be
modified. The only backend sending repeated events is X11, thus for
other backends it should be enabled.
Whether creating a timer on each key event is a good idea is something to
evaluate in future.
Reviewed-By: Bhushan Shah
Similar to the change regarding pointer and touch a
KeyboardInputRedirection is created. The Xkb class is also moved to
the new files keyboard_input.h and keyboard_input.cpp.
Just like in the case of PointerInputRedirection no signals are added,
but the existing signals in InputRedirection are directly invoked.
