Summary:
Gesture events are swipe or pinch events on a touch pad.
This change implements basic support by:
* wrapping them in LibInput::Event
* processing them in LibInput::Connection and emitting
dedicated signals
* Forwarding them in InputRedirection to PointerInputRedirection
* Support them in the internal input event filter
* Printing debug information in DebugConsole
Further handling is not yet done. In future the following should be
implemented:
* activating e.g. zoom and present windows on pinch/swipe gesture
* forwarding non global gestures to KWayland
Note that forwarding to KWayland is not yet useful as QtWayland does
not yet have support for the unstable protocol. No Qt application could
make use of it yet. So for the moment just global gestures is the best
we can get.
Test Plan: Looked at output of DebugConsole when triggering gestures
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2359
Summary:
This is a workaround for QTBUG-54371 resulting in QtWayland never
requesting the input methods panel without having keyboard focus.
Thus also the virtual keyboard is not working.
With this change we go back to always announcing a keyboard and
binding the virtual keyboard to whether we don't have an alpha-numeric
keyboard instead of whether there is a keyboard on the seat.
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2343
Summary:
Qt's touch event API is rather difficult and complex to implement.
As none of KWin's internal windows supports multi-touch gestures yet,
this is going the easy route and just simulates a left mouse button
press. If in future need arises for touch gesture support on KWin's
internal windows, this can be added.
Test Plan: Tested on exopc with DebugConsole and auto test
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1661
Summary:
Touch events are emulating mouse events, in particular left mouse
button.
With this change one can move windows through the decoration, use
the decoration buttons and also support the double click action.
As finding the decoration is pretty much exactly the same as for
pointer events, a new base class is introduces which provides the
functionality of updating the decoration and the shared common
variables.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1604
Summary:
The configuration file kcminput, group Mouse is parsed to decide whether
pointer devices should be in left handed mode. The config is applied
whenever a new device is added.
In addition the Connection listens to KGlobalSettings for a mouse
settings changed signal which might be emitted by the mouse KCM.
When such a signal is emitted, all pointer devices are reconfigured.
This allows to change the mouse handed settings on Wayland.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1543
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
So far the DrmOutput connected to all input events when going into
power saving. As we now have the input filters it's better to just
install a filter when an output goes into powersave and remove the
input filter again when all outputs are enabled again.
To make this work InputRedirection gains a new method to add a new
filter as the first filter. This is a potentially dangerous method
as it allows to have a filter before LockScreenFilter gets the
events. But in case of DPMS it's something we actually want.
A nice new feature possible with the input filter is that we can
filter out the event which re-enables the outputs. Thus when getting
on a system with output off and screen locked, the first key hit
doesn't go to the lock screen.
Reviewed-By: Bhushan Shah
BUG: 341201
Fixed-in: 5.6.0 (Wayland-only)
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.
All pointer related code is moved into a new class called
PointerInputRedirection.
The main idea is to simplify the code and make it easier to maintain.
Therefore also a few changes in the setup were performed:
* before init() is called, no processing is performed
* init() is only called on Wayland and after Workspace is created
* init property is set to false once Workspace or WaylandServer is
destroyed
Thus code can operate on the following assumptions:
* Workspace is valid
* WaylandServer is valid
* ScreenLocker integration is used
The various checks whether there is a waylandServer() and whether
there is a seat are no longer needed.
Some of the checks have been reordered to be faster in the most common
use case of using libinput. E.g. whether warping is supported is first
evaluated by the variable bound to whether we have libinput and only if
that is false the backend is checked.
The new class doesn't have signals but invokes the signals provided
by InputRedirection. I didn't want to add new signals as I consider
them as not needed. The areas in KWin needing those signals should
be ported to InputEventFilters.
When the screen gets locked any existing sequence gets cancelled
and the focused touch surface gets reset. While screen is locked
touch events are filtered to only go to lock screen or input methods.
Test case is added for touch event during lock screen.
Reviewed-By: Bhushan Shah
Instead of only making the active client the focused keyboard surface,
the method now also performs the lock screen security restriction.
Also just like udatePointerWindow the method becomes public, so that
it can be used from the LockScreenEventFilter and is connected for
lock state changes. This means as soon as the screen locks the current
focused keyboard surface will get a leave event and get an enter event
once the screen unlocks.
The auto test is adjusted to verify these new conditions.
Reviewed-By: Bhushan Shah
The main motivation of this change is to remove the spaghetti code
in the input event handling. Each area of processing (e.g. lock screen)
is moved into a dedicated event filter. Processing the events now just
means calling a virtual method on each of the filters. As soon as the
method returns true, the processing is stopped.
This allows to have the security for the lock screen just in one place:
whenever the screen is locked the event filter can ensure that the events
are not further processed.
Currently all event filters are implemented directly in input.cpp and
are registered by InputRedirection itself. In future it would be better
to have those moved to the area they belong to and get registered from
there. E.g. the input filter for EffectsHandlerImpl should be created
by EffectsHandlerImpl. This requires an improved API to ensure that the
filters are installed in the correct sequence.
We take the configuration from the kcminputrc config file, group
keyboard (see plasma-desktop.git/kcms/keyboard/kcmmisc.cpp)
The values are only used for libinput. For backends providing input
events we expect to get repeated key events anyway.
On popular demand!
This change tracks how modifiers are used and detects a modifier only
key press/release. That is:
* no other key is pressed when the modifier gets pressed
* no other key gets pressed before the modifier gets released
If such a press/release is detected, we call a configurable dbus call.
The possible shortcuts can be configured in kwinrc, group
"ModifierOnlyShortcuts". The following keys are supported:
* Shift
* Control
* Alt
* Meta
As value it takes a QStringList (comma seperated string) with
service,path,interface,method,additionalargs
E.g. to invoke Desktop Grid effect on Meta key:
[ModifierOnlyShortcuts]
Meta=org.kde.kglobalaccel,/component/kwin/,org.kde.kglobalaccel.Component,invokeShortcut,ShowDesktopGrid
I do not intend to add a config interface for it. Let's keep it a hidden
way.
REVIEW: 124954
The KGlobalAccelD which gets created by KWin needs a plugin for the
platform specific parts. This change introduces such a plugin. It's
linked against kwin so that it can integrate with the core.
On enable the plugin registers itself in the InputRedirection and
GlobalShortcutsManager checks the plugin whether a shortcut got
triggered.
As the loading of the plugin must happen after InputRedirection is
fully created a dedicated init method is added to InputRedirection.
REVIEW: 124187
We used to change it only on keypresses. This resulted in the strange
situation that e.g. the input method virtual keyboard doesn't show up
until one presses a real key, because e.g. maliit only activates the
keyboard if there is an active focus object in the Qt application.
If there is a visible internal window it gets the pointer events.
The assumption is that the last created internal window is the top
most in stacking order.
So far input events were sent through Xwayland which is not needed as
we have all information available. Even more it had the pointer surface
on the wrong window when interacting with decorations as it was on the
window and not on the decoration.
When creating a new xkb keymap we need to pass it to the Wayland server's
seat. As the Wayland protocol expects the keymap as a file descriptor, a
temporary file is created, mmapped and the keymap written into it. As
the Wayland protocol doesn't restrict how long the file descriptor needs
to be valid we keep any created temporary file around till the
InputRedirection gets destroyed.
This change is motivated by the fact that we need to suspend libinput
before switching the virtual terminal. Also we don't want to take over
libinput if we do not have a VirtualTerminal created - in windowed mode
we don't want libinput to be started. So binding it to the backends which
create the VirtualTerminal makes sense.
The KWin::Application gains a new signal virtualTerminalCreated which is
emitted from VirtualTerminal once it's properly setup. This is used by
Input to create Libinput integration instead of binding it to logind.
Furthermore Libinput gets suspended when the VirtualTerminal reports that
it is no longer active. For re-activation we still just use logind's
session active property.
InputRedirection gains basic support for processing touch events which
are delegated to KWayland::Server.
WaylandBackend accepts touch events from KWayland::Client and delegates
them to the InputRedirection.
Pointer events are no longer sent through the methods on Toplevel,
but properly sent through the SeatInterface. This has the advantage
that SeatInterface properly tracks which is the focused pointer surface
and does not need to use the xtest extension.
KGlobalAccel sets the timestamp as a property and we need to set our
x11Time to it otherwise following keyboard grabs might fail.
Requires 61e2a156678eef033b2629f7c72530dc78d7c3ac in kglobalaccel.
We don't want the cursor to leave the visible area, so better check that
the cursor doesn't leave it. And when the screens changes better check
that the cursor is still on a visible screen. If not: put it back to the
center of the closest screen.
With libinput we have the problem that we need to have privileges to
open the device files. In order to not need wrappers or suid bits, we
use logind. This means that kwin_wayland has to be the session controler.
A LogindIntegration is added to connect to logind and wrap the dbus
calls. This is based on the logind integration done for ksld in
ksmserver. The LogindIntegration is started by Workspace and the
InputRedirection tries to become the session controller and starts the
libinput integration only after this succeeded.
Some systems (e.g. openSuSE) don't install the xkbcommon header into
/usr/include/xkbcommon/xkbcommon.h (which is always in the include path),
but instead into a subdirectory, which is in the openSuSE case
/usr/include/pkg/libxkbcommon/xkbcommon/xkbcommon.h. This means that e.g.
kcm_kwinrules will not compile there since it includes input.h
REVIEW: 117069
Used by Cursor to properly emit the mouseChanged signal which for
historic reasons includes the keyboard modifiers.
Again some fiddling around with the autotests and kcmrules needed to
make it compile. This needs improvement!
A new GlobalShortcutsManager is introduced which is responsible for
holding the registered shortcuts and triggering the matching action.
The InputRedirection checks with the GlobalShortcutManager whether a key
press event triggers a global shortcut and stops processing the event in
that case.
At the moment the GlobalShortcutsManager only supports the very basics
for KWin internal usage. External applications can not yet make usage of
the global shortcut system inside KWin.
Major new functionality is xkbcommon support. InputRedirection holds an
instance to a small wrapper class which has the xkb context, keymap and
state. The keymap is initialied from the file descriptor we get from the
Wayland backend.
InputRedirection uses this to translate the keycodes into keysymbols and
to QString and to track the modifiers as provided by the
Qt::KeybordModifiers flags.
This provides us enough information for internal usage (e.g. pass through
effects if they have "grabbed" the keyboard).
If KWin doesn't filter out the key events, it passes them on to the
currently active Client respectively an unmanaged on top of the stack.
This needs still some improvement (not each unmanaged should get the
event). The Client/Unmnaged still uses xtest extension to send the key
events to the window. So keylogging is still possible.
InputRedirection keeps track of the Toplevel which is currently the one
which should get pointer events. This is determined by checking whether
there is an Unmanaged or a Client at the pointer position. At the moment
this is still slightly incorrect, e.g. pointer grabs are ignored,
unmanaged are not checked whether they are output only and input shapes
are not yet tracked.
The pointer events are delivered to the Toplevel as:
* enter
* leave
* move
* button press
* axis event
Nevertheless move events are still generated in InputRedirection through
xcb test for simplicity. They are still send to the root window, so all
windows get mouse move.
Button press and axis are generated only in the implementations of the
event handlers and delivered directly to the window, so other windows
won't see it.
New inheriting class which uses the InputRedirection to track the cursor
position. It doesn't support warping of cursor.
This introduces a slight dependency loop in the startup. Cursor needs to
be created after the WaylandBackend to ensure that the operation mode is
set correctly. But the WaylandBackend itself is accessing Cursor. It
should be safe as inside the WaylandBackend it's only accessed after
callbacks.
