GitLab

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:
The Xkb class loads keyboard layouts from the users configuration. This
makes tests fail locally if the user has a layout which behaves
differently to the one the test expects. E.g. on a German layout the
right alt key is different to the one of US layout.

In order to have a more stable test base the env variable
KWIN_XKB_DEFAULT_KEYMAP forces the loading of the default keymap, thus
tests have a common layout set.

Reviewers: #kwin, #plasma_on_wayland

Subscribers: plasma-devel, kwin

Tags: #plasma_on_wayland, #kwin

Differential Revision: https://phabricator.kde.org/D2466

Summary:
With this change KWin/X11 reuses Wayland's modifier only shortcut
architecture. The XInput2 event filter also listens for
 * XI_RawKeyPress
 * XI_RawKeyRelease

Those events are also reported if another X11 client grabs keyboard
input. Thus KWin gets all key events, just like on Wayland.

All key events are then sent through the Xkb class which performs the
mapping from key codes to key syms and is able to detect whether the
modifier got pressed/released without another key being pressed.

This change will require a few follow up changes, which are required
also for Wayland:
 * ignore if another input device got interacted (e.g. mouse press,
   touch screen, scroll, etc)
 * use the layout from XServer instead of using our own (needed on
   Wayland in nested setup)

The biggest disadvantage of the change is that it triggers a wake
up of KWin on every key event. But as KWin already listens to all
pointer events that's not a big difference and normally a key event
will wake up the compositor any way.

Reviewers: #plasma

Subscribers: kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D2425

If the screen is locked the modifier only shortcuts should not trigger.
Also if the screen gets locked while a modifier is hold the shortcuts
should not trigger.

Reviewed-By: bshah

Summary:
If the user clicked a pointer button or scrolled a pointer axis the
held modifier was most likely intended to modify the pointer event.
Thus the modifier only shortcut should not be triggered.

Reviewers: #kwin, #plasma_on_wayland

Subscribers: plasma-devel, kwin

Tags: #plasma_on_wayland, #kwin

Differential Revision: https://phabricator.kde.org/D2435

Summary:
The clipboard sync is done by a dedicated helper binary launched by
KWin. This helper binary is forced to xcb platform to piggy-back on
Qt's implementation of the X11 clipboard. In addition it implements
the Wayland clipboard - which is much simpler. Reading the Wayland
clipboard is based on the implementation in QtWayland.

KWin internally knows the DataDeviceInterface belonging to the helper
application. Whenever an xwayland client is focussed, this DataDevice
is allowed to set the selection and KWin manually updates the current
selection in the SeatInterface. By that the sync from X11 to Wayland
is implemented. When afterwards a Wayland client is selected, it's sent
the current selection which references the X clipboard and a data
transfer can be initiated in the normal Wayland way.

For the other direction KWin sends the current selection to the helper's
DataDevice whenever an xwayland window is focused. The helper application
reads the Wayland clipboard and sets it on the X11 clipboard. Thus the
Wayland clipboard is synced to X11.

The approach used here will also be useful for implementing a clipboard
manager (aka klipper).

Currently the implementation is not yet fully completed. We need to
make sure that the helper application gets restarted in case of a crash.

Test Plan: See added test case

Reviewers: #plasma_on_wayland, #kwin

Subscribers: plasma-devel, kwin

Tags: #plasma_on_wayland, #kwin

Differential Revision: https://phabricator.kde.org/D1973

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

Summary:
In order to start the WaylandServer in kwin_x11 we need to make sure
that WaylandServer does not start the KScreenLocker integration. On
X11 the lock screen is provided by a different application (in Plasma
by ksmserver).

A new init flag is added to WaylandServer to not integrate with
KScreenLocker. Thus the default is still to integrate with KScreenLocker.

All direct usages of KScreenLocker are guarded to not be called if
the screenlocker integration is not present.

Reviewers: #plasma

Subscribers: plasma-devel

Projects: #plasma

Differential Revision: https://phabricator.kde.org/D1481

Like cc64bb25 just for xkb.

By connecting to the signal KWin can reload the keyboard layout
configuration and adjust to changes in the configuration module.

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.

The layout might have changed, thus we should notify the client about
it. The server ensures that on no state change it's not sent to the
client.

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.

The keymap knows whether the key should repeat or not. E.g. no need to
trigger repeat for modifier keys.

Forward all debug messages from xkbcommon to our own categorized
logging.

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.