Summary:
This change finds the screen for a touch screen device based on:
* number available screens
* output name defined on the touch screen device
* internal screen
* and physical size
The id of the screen is stored in the Device allowing to adjust the
touch points accordingly. This means instead of transferring to the
combined display size the touch points are transferred into the output
space and the position of the output is added. Thus in a multi screen
system the touch points are properly mapped to the output.
Furthermore the screen orientation is passed to the Device and a
calibration matrix is set accordingly. Thus a transformed screen has the
touch screen transformed accordingly.
Please note that this only affects libinput on Wayland and not on X11!
The x11 standalone platform needs to gain similar code.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8748
Summary:
In some cases, it's possible that libinput wrote device added events to
the file descriptor before the connection to handle those events was
in-place. This resulted in a compositor without any input devices.
Test Plan:
Ran a wayland session. In about 60% of all cases, no input was
possible. kwin_libinput showed the enumeration of all devices correctly,
but KWin::LibInput::Context did not have any m_devices.
After this change, this did not appear anymore.
Reviewers: #plasma, graesslin, davidedmundson
Reviewed By: #plasma, graesslin, davidedmundson
Subscribers: anthonyfieroni, ngraham, kwin, #kwin, plasma-devel
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8888
Summary:
On X11 modifier+mouse button on the window decoration triggers the
"special" handling thus as unrestricted move instead of passing the click
to the decoration. Of course on Wayland we want to have the same
functionality.
BUG: 386708
FIXED-IN: 5.11.4
Test Plan: New test case added. PointerInputTest still passes.
Reviewers: #kwin, #plasma, broulik
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8758
Summary:
The SCHED_RESET_ON_FORK results in threads (not only processes) to have
the scheduling policy reset to default. This means that the libinput
thread is not real time, but this was actually intended.
To solve this problem KWin does start without the RESET_ON_FORK flag
during startup. Once createInput has been called the scheduling is
adjusted again and RESET_ON_FORK is added again. This results in the
libinput thread and all threads Qt starts in between (e.g. dbus) to gain
real time policy. But it is still not leaked to other processes or to
threads in KWin which don't need it.
Other options considered: just don't use RESET_ON_FORK and instead
manually reset on fork. This would mean all threads in KWin gain real
time, but we don't need this. It's only interesting for the main
(rendering, Wayland thread) and the input thread. Also the danger to
leak into another process is too high.
Keeping the capability till the libinput thread is created and adjust
the thread itself. This option was discarded as I don't want KWin to
have any capabilities when the QApplication is started.
Test Plan: ps -eL -o class,rtprio,cmd,comm | grep kwin_wayland
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8065
Summary:
KWin passes the current keysym converted to a Qt::Key in the QKeyEvent.
The current keysym does not always change when a key gets released, so
when pressing a shortcut the release carry a Qt::Key which could be
considered as wrong.
QtWayland transforms the actual pressed/released key into a keysym and
passes that through the QKeyEvent. This change does the same for the
internal windows. A new QKeyEvent is created and adjusted in a way that
it matches what Qt expects.
Why not change everything to how Qt expects it? The key is used at
various places and in KWin internally we expect the behavior how it is
currently implemented. So it's better to use Qt's expectation only when
interacting with Qt.
Also the change carries a workaround for a bug in QKeySequenceEdit
(see QTBUG-62102) and transforms Super to Meta. As this adjustment only
makes sense for the internal windows we need to send in an adjusted
QKeyEvent anyway, so another argument for using the Qt behavior only in
this place.
Test Plan:
Can set a shortcut on Wayland and it can be used to activate
the window.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D6828
Summary:
So far KWin started to filter out the escape key as soon as it gets
pressed. This was done by unsetting keyboard focus. The idea was to
reset keyboard focus when it is only a short press and that then the
keyboard state is correct for the application. But in practice this
does not work. The only application currently supporting pointer
constraints (Xwayland) does not do anything on a key which is pressed
when gaining keyboard focus. The result is escape not working in
pointer constrained Xwayland windows.
This change addresses this problem by changing the interaction to only
unset keyboard focus when our break constraints condition is met. This
should also result in the application not handling the key release, but
it means it gets the key press. Unfortunately I don't have a good way
to test.
BUG: 378452
Test Plan: None
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5488
Summary:
Making QActions with the Connection as a parent is dangerous as it gets
moved to a new thread, moving all child objects to that thread.
KGlobalAccel and QAction aren't thread safe and we shouldn't be using it
in two threads. This was notably seen when runnng invokeShortcut over
DBus which then invokes it on the main thread. Something my laptop was
doing when I closed the lid.
This patch simply moves the code to the Input class, where we set up the
libinput connection.
Test Plan:
Closed lid, kwin_wayland was still there when I resumed
Set manual shortcut for toggling touchpad, that still worked
Reviewers: #plasma
Subscribers: plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5733
Summary:
There are a few places where KWin needs to read values from kcminputrc.
As I need to add yet another one it makes more sense to properly
structure it like in other cases and have only one kcminputrc hold in
the application. This also allows to better mock the config values in
the integration tests.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5540
Summary:
During pointer motion we already had the condition that an update of
focused pointer surface can only happen when no button is pressed. But
there are more conditions where we try to update the focused pointer even
if a button is pressed. E.g. if the stacking order changes.
This happens when trying to move one of Qt's dock widgets:
1. Press inside a dock widget
2. Qt opens another window, which is underneath the cursor
3. KWin sends pointer leave to parent window
4. dock widget movement breaks
This change ensures that also this sequence works as expected and the
pointer gets only updated when there are no buttons pressed, no matter
from where we go into the update code path.
BUG: 372876
Test Plan: Dock widgets in Dolphin can be moved now.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5461
Summary:
So far KWin did not properly handle popup windows. That is when a popup
surface got created and a click outside the surface happened KWin did not
send out the popupDone Wayland event.
This change makes KWin aware of whether a surface is a popup and tracks
through a new PopupInputFilter whether there are popup windows. In case
there are popups the new filter waits for mouse press events and cancels
the popups if the press does not happen on any surface belonging to the
same client. To quote the relevant section of the Wayland documentation:
The popup grab continues until the window is destroyed or a mouse
button is pressed in any other client's window. A click in any of the
client's surfaces is reported as normal, however, clicks in other
clients' surfaces will be discarded and trigger the callback.
So far the support is still incomplete. Not yet implemented are:
* support xdg_shell popup windows
* verifying whether the popup is allowed to be a popup
* cancel the popup on more global interactions like screen lock or
kwin effect
BUG: 366609
FIXED-IN: 5.10
Test Plan: Auto test and manual testing with QtWayland client
Reviewers: #plasma, #kwin
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5177
Summary:
This was forgotten during implementing the interactive window/point
selection. With this change it is also possible to perform the
interaction through touch events. In that case KWin takes over any
existing touch sequence.
This implements T5315.
Test Plan: Added auto test and took a screenshot through touch events
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5203
Summary:
Each Edge creates a SwipeGesture for touch activation. The swipe needs to
be a single finger starting from the edge into the screen for at least
20 %. The SwipeGesture and GestureRecognizer is extended to support the
use cases of the touch screen edge swipe.
New features supported by the gesture system are:
* minimum and maximum position
* a minimum delta for the swipe
* progress signal based on the minimum delta
* starting a swipe with a start point
The Edge has the progress signal connected to its approach signal, thus
visual feedback is provided through the screen edge effect.
The screen edge system supports touch only for the edges (corners are
too difficult to activate on touch screens). At the moment the following
features are supported:
* screen edge show/raise of windows (e.g. auto hidden panels)
* trigger the configured action
* trigger the configured callback function (e.g. script)
In future it might make sense to add a touch specific configuration
action to support different actions for screen edges activated by mouse
and touch.
BUG: 370323
Test Plan:
configured a screen edge and triggered through touch,
added an auto-hiding panel and triggered through touch
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D5106
Summary:
This change adds global touchpad swipe gestures to the
GlobalShortcutsManager and hooks up the swipe gestures as defined at the
Plasma Affenfels sprint:
* swipe up: Desktop Grid
* swipe down: Present Windows
* swipe left: previous virtual desktop
* swipe right: next virtual desktop
The main work is handled by two new classes: SwipeGesture and
GestureRecognizer. This is implemented in a way that it can be extended
to also recognize touch screen gestures and pinch gestures.
The SwipeGesture defines what is required for the gesture to trigger.
Currently this includes the minimum and maximum number of fingers
participating in the gesture and the direction. The gesture gets
registered in the GestureRecognizer.
The events for the gesture are fed into the GestureRecognizer. It
evaluates which gestures could trigger and tracks them for every update
of the gesture. In the process of the gesture tracking the
GestureRecognizer emits signals on the Gesture:
* started: when the Gesture gets considered for a sequence
* cancelled: the Gesture no longer matches the sequence
* triggered: the sequence ended and the Gesture still matches
The remaining changes are related to hook up the existing shortcut
framework with the new touchpad gestures. The GlobalShortcutManager
gained support for it, InputRedirection and EffectsHandler offer methods
to register a QAction. VirtualDesktopManager, PresentWindows and
DesktopGrid are adjusted to support the gesture.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D5097
Summary:
During the Wayland porting a KWin internal global shortcut handling got
implemented prior to the porting of KGlobalAccel. This allowed to trigger
global shortcuts with a KGlobalAccel still on X11 and unknown to KWin.
Nowadays KWin directly provides KGlobalAccel, thus it's no longer
required. The code was runtime dead as we always have a KGlobalAccel.
Reviewers: #plasma, #kwin
Subscribers: plasma-devel
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D4165
Summary:
InputRedirection has a workaround to add a connect on a QAction which
is used for a global shortcut. This is specific to the X11 platform as
the xtime needs to be updated.
This change adds a new virtual method to the Platform and moves the
implementation into the X11 standalone platform. Thus it does no longer
gets called on Wayland.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D4168
Summary:
An improvement from the introduction of InputEventSpy. Instead of
specifying a std::function as argument, we let the compiler decide what
is the best argument.
Reviewers: #kwin, #plasma, mart
Reviewed By: mart
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3877
Summary:
Adjusting to a difference from introducing the InputEventSpy. A filter
may only be installed once. Thus removeOne is totally sufficient.
Added a Q_ASSERT to ensure that it is not installed when installing.
Reviewers: #kwin, #plasma, mart
Reviewed By: mart
Subscribers: mart, plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3878
Summary:
So far KWin's input event processing is mostly based on
InputEventFilters. A filter can - as the name suggest - filter out an
input event from further processing. Our code shows that this is not
sufficient for all input event processing.
We have several areas inside KWin where we need to have access to all
input events, where the processing needs to happen on all events and
filtering is not allowed. This results in sub-optimal code which has
classes which know too much and do too much.
Examples:
* key-repeat handling done in KeyboardInputRedirection
* Layout change OSD in Xkb
* modifier only shortcuts in Xkb
* emitting signals for Cursor class in KeyboardInputRedirection
Also there are misuses of the InputEventFilters and internal API
* DebugConsole keyboard state (uses wrong information)
* DebugConsole input events tab (uses Filter, should be a spy)
This change introduces the API needed to fix these problems. It
introduces an InputEventSpy which is modelled after the InputEventFilter
with the difference that it has only void messages and uses the KWin
introduced event classes.
The spies are always processed prior to the filters, thus we know it can
have all events.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3863
Summary:
Prior to this change various event filters performed deep calls into
Xkb class to figure out the modifiers relevant for global shortcuts (aka
consumed modifiers). This shows that this is a general useful
information which should be available to all input event filters
directly.
Thus it's now added to the input events and exposed directly in
InputRedirection so that the calls into Xkb are no longer needed.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3810
Summary:
For every input event we have similar code. We go through all
InputFilters, invoke a method with some arguments and check whether
the filter returns true.
Instead of duplicating that logic everywhere, there is now one method
in InputRedirection which takes a std::function to call on the input
filters. The std::function is supposed to be generated with a std::bind
on the InputFilter::method with all the required arguments.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3806
Summary:
There are two types of constraints supported:
1. Pointer confinement
2. Pointer locking
In the case of confinement the pointer is confined to a given region of
the surface. This is comparable to general operation where the pointer
is confined to the screen region.
In the second case the pointer gets locked. That means it cannot move at
all. No further position updates are provided, only relative motion
events can go to the application. There is a hint about cursor position
update on unlock which is not yet implemented in KWayland::Server, thus
also not in this change.
The implementation in KWin grants the requests for pointer constraints
when the pointer enters the constrained region, either by pointer
movement or by e.g. stacking order changes. There is no confirmation
from user required to enter that mode. But we want to show an OSD when
the pointer gets constrained, this is not yet implemented, though.
Breaking an active constraint is relatively easy. E.g. changing the
stacking order will break the constraint if another surface is under the
cursor. Also (in case of confinement) moving the pointer to an
overlapping window breaks the confinement. But as soon as one moves the
pointer back to the window a constraint might get honoured again.
To properly break there is a dedicated event filter. It listens for a
long press of the Escape key. If hold for 3sec the pointer constraint is
broken and not activated again till the pointer got moved out of the
window. Afterward when moving in the pointer might activate again.
The escape filter ensures that the key press is forwarded to the
application if it's a short press or if another key gets pressed during
the three seconds. If the three seconds way fires, the later escape
release is not sent to the application.
This basic interaction is also ensured through an added auto test.
This change implements T4605.
Test Plan: Added auto test and nested KWin Wayland with D3488
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3506
Summary:
A second interactive selection mode gets added to select a position on
the screen. This is handled by the same input event filter as for the
window selection. Just that instead of returning a window, it returns a
QPoint.
This allows to pick a point on the screen which we need to screenshot
the screen under the mouse cursor and in future for color picking.
The screenshot effect provides two new dbus methods to (interactively)
select a screen or fullscreen. This allows spectacle to screenshot the
(full) screen with still having the user in control.
Reviewers: #kwin, #plasma_on_wayland, bgupta
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3475
Summary:
The interactive window selection is implemented in InputRedirection
through a dedicated InputEventFilter. The InputEventFilter so far takes
care of pointer input and keyboard input. In addition it ensures that
keyboard and pointer focus is reset on start and on end.
With this change KillWindow now also works on Wayland, but only for X11
windows, as the Wayland variant is not yet implemented.
Test Plan: Tested in nested setup, auto-tests still needed
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3365
Summary:
The interactive window selection is implemented in InputRedirection
through a dedicated InputEventFilter. The InputEventFilter so far takes
care of pointer input and keyboard input. In addition it ensures that
keyboard and pointer focus is reset on start and on end.
With this change KillWindow now also works on Wayland, but only for X11
windows, as the Wayland variant is not yet implemented.
Test Plan: Tested in nested setup, auto-tests still needed
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3365
Summary:
This change implements forwarding the pointer gestures to the new API in
SeatInterface.
While screen is locked no gestures are forwarded to the server. Also
locking the screen cancels any active gesture. Similar if areas inside
KWin would start to intercept the gestures, they need to be cancelled on
the Wayland SeatInterface.
Test Plan: Not yet
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3174
Summary:
For whatever reason Qt scrolled the wrong way on internal windows. As a
new QWheelEvent is constructed anyway, just multiply by -1 to get the
direction fixed.
BUG: 371999
FIXED-IN: 5.8.4
Test Plan: Tried debug console in nested setup, scrolled correctly now.
Reviewers: #kwin, #plasma_on_wayland, broulik
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3247
Summary:
The Xkb implementation starts to track the state of the LEDs in the
keymap and emits a signal whenever the LEDs change. This signal is
connected to a method in LibInput::Connection which updates the led
state on all devices and uses it to init the state of the led when a new
device gets connected.
BUG: 369214
FIXED-IN: 5.8.2
Test Plan: Connected a keyboard with LEDs and enabled NumLock and ScrollLock.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2943
Summary:
If KWin interacts with Libinput the RelativePointerManager interface
gets created on the Wayland server. The ForwardInputEventFilter does
forward the relative motion events in addition to the normal motion
events.
In order to properly support the relative motion events as they are
expected by the Wayland protocol the handling of pointer motion events
got slightly adjusted:
* Libinput Pointer event extended by the additional data points
* Libinput Pointer event carries the delta as a QSizeF instead of
QPointF
* PointerInputRedirection adjusted to take a pointer motion event with
more arguments
* Custom QMouseEvent subclass adjusted to carry the additional members
The DebugConsole is adjusted to show the relative motion events in
addition to the global position.
Test Plan:
Verified the manager object is created and verified the
events in DebugConsole. Unfortunately not aware of any test application.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2979
Summary:
This change adds support for resizing outside the window decoration
(e.g. setting borders to NoSide or None).
To support this a new Toplevel::inputGeometry() -> QRect method is
added which exposes the geometry adjusted by the margins provided by
the decoration. This is checked in InputRedirection when finding a
Toplevel at a given position. The logic for figuring out whether the
event should go to the decoration or the window already handled the
situation correctly, so no further changes are needed.
BUG: 364607
FIXED-IN: 5.8.1
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2787
So far this method translated the keysym to Qt::Key. This is no longer
needed as the only method which invokes processKey has access to the
translated key. Thus saving one translation for every key press.
Reviewed-By: bshah
A new protected method is added to InputEventFilter to forward a
QKeyEvent to the Wayland server. Several input filters need to forward
the event to have a proper state of the events. E.g. the TabBox filter,
but also the internal window filter and effects filter. It's important
to update all events even if the events are not forwarded to a surface.
This new method takes care of the general handling like ignoring key
repeats, etc.
Reviewed-By: bshah
When Alt+(Shift)+Tab is grabbed we have the modifier press key being
passed to the Wayland server as key events are not yet grabbed. As KWin
grabbed the release event the Wayland server considered the key still as
pressed when going into the next application.
This change ensures that all events are also passed to the wayland
server. As no surface has focus we can be sure that it won't be passed
to the application, but it ensures that the events are processed
correctly.
Reviewed-By: bshah
Summary:
The interaction is changed to trigger the check for release from the
TabBoxInputFilter instead of reacting on modifier changes. That way
it's possible to check for the relevant modifiers getting released
instead of getting all modifiers in. Also this means that the checks
are only performed when relevant.
BUG: 368590
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2773
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:
In order to add more tabs which can further help monitoring how KWin
handles some aspects the DebugConsole is changed to not take keyboard
input. This means it can only be navigated using pointer device or touch
screen.
This is needed for adding a new tab to monitor clipboard changes. On
Wayland sometimes windows don't get the clipboard, so it would be
helpful to have a debug monitor to see when the clipboard changes. But
for that debug console window may not take keyboard events.
To support this DebugConsole sets the WA_ShowWithoutActivating attribute
which gets honored by the InternalWindowEventFilter and does not forward
key events to such windows.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2620
Summary:
The Effect class is extended by three new virtual methods:
* touchDown
* touchMotion
* touchUp
The methods return a boolean value so that the events can be filtered
out. E.g. an effect which has also a mouse grab installed wants to
filter out all events, other effects don't need the events exclusively.
This is a difference to how e.g. keyboard and pointer events are handled.
But is more close to how KWin's internal input event passing works and
makes it easier to get touch event: one does not explicitly has to grab
the events. It's also closer to Wayland where all input events are
available.
As a first example the Present Windows effect is adjusted and allows to
activate windows through the touch screen. As much code as possible is
shared with pointer input.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2450
Summary:
So far when KWin intercepted a key event a leave was not sent to the
Wayland surface currently having keyboard focus. This could result in
the Wayland application to start repeating keys. E.g.
1. application gets key press event
2. This triggers an internal window to show
3. key release goes to KWin internal window
4. application starts to repeat key as there is no release
With this change whenever KWin intercepts the key event e.g. due to
* internal window
* Effects grabbing key event
* Tabbox
the focused keyboard surface is set to null, thus triggering a leave
event and the client not starting to repeat the event.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2402
Summary:
Restores feature parity with X11. Global shortcuts need to trigger
also for repeat events. An example is the volume key or screen
brightness.
For other shortcuts like showing yakuake it does not make sense to
trigger on repeat. Thus a long term solution is to add a flag to
global shortcuts whether the key should trigger on repeat.
BUG: 366608
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2413
Summary:
With this change KWin can create window decorations for internal windows.
Thus it's also possible to move internal windows and resize them which is
especially important for the debug console.
Reviewers: #kwin, #plasma_on_wayland, sebas
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2371
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:
So far when a ShellClient got unmapped ready_for_painting was set to
false. That is the ShellClient was treated in the same way as a not
yet shown window. It was completely excluded from painting, a close
animation impossible.
This change makes use of the functionality available in
Client::hiddenInternal(). The window is considered as hidden, thus
still excluded from e.g. getting input events, but could be rendered
any time as we still have a previous window pixmap (if referenced).
This allows to have it considered in the rendering pass, but effects
still cannot make use of it as that state is not yet exposed to the
effects.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2083
The id we internally have is a signed int and might be negative, but
the touch id we get is unsigned. We can savely cast the unsigned to
signed as touch ids are recycled and more than 10 touch points is
unlikely to be useful.
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:
Just because we have a power button, doesn't mean we have a keyboard.
So let's bind the seat keyboard to whether we have a proper keyboard.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1681
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:
Mouse actions like wheel and double click were restricted to the titleBar
area. This made the top most pixel non-interactive as it's not part of the
titleBarArea.
This change makes the complete titlebarPosition interactive. That is it
includes for a "normal" (top) setup also the TopLeft/Top/Right section.
Thus the top most pixel can be double clicked, mouse wheeled, etc.
For the Wayland case the test case is adjusted.
BUG: 362860
FIXED-IN: 5.7.0
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1596
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
All the important information like whether we are on the active vt are
also provided by Logind. So instead of integrating with VirtualTerminal,
which integrates with Logind, we can just integrate with Logind directly.
On special request by sebas. It's not really dangerous as by default
the xkb layout doesn't have it enabled. So if a user actually enables
it, we can also support it.
And now I'm going to reconfigure my layout again to not hit it by chance.
Reviewed-By: sebas
We want TabBox to operate on key press, not on key release. So far
it only operated on release as the press was filtered out by the
global shortcuts filter. To prevent that the tab box filter is moved
before the global shortcuts filter.
Note: first usage of TabBox has current window selected instead of
next. This problem is also visible on X11.
The TabBox implements methods for those events and performs same
logic as on X11. Click outside of TabBox closes. If the event is on
the TabBox we don't filter the event out and let the internal filter
forward the event.
Drag'n'Drop on Wayland allows us to improve the drag'n'drop experience.
When entering a window during the drag'n'drop operation, KWin raises it.
BUG: 36065
FIXED-IN: 5.6.0 (Wayland only)
When starting effect mouse interception the current focused window
and or decoration should get a leave event. Similar when the effect mouse
interception ends the current pointer position needs to be evaluated and
a pointer enter be sent if needed.
So far updating the cursor image was not really defined. It was possible
to use the cursor image from the wayland seat or have a custom set cursor
image. But there are no rules in place to decide which one to use when.
With this change a dedicated CursorImage class is introduced which tracks
the cursor image changes on the seat, on the decoration, in the effects
and so on. In addition it tracks which is the current source for the
image, that is whether e.g. the cursor from the seat or from effects
override should be used. Whenever the cursor image changes a signal is
emitted, which is connected to the signal in AbstractBackend.
Based on that the backends can directly show the image. The existing
code in the backends to install a cursor shape or to install the cursor
from the server is completely dropped. For the backend it's irrelevant
from where the image comes from.
A new feature added is that the cursor image is marked as rendered. This
is then passed on to the frame rendered in the Surface and thus animated
cursors are finally working. Unfortunately animated cursors are broken in
Qt (see https://bugreports.qt.io/browse/QTBUG-48181 ).
Small regression: the command didn't get updated at all, so it was always
MouseNothing.
To prevent such a regression to sneak in again the change comes with
autotest for the action on inactive and active window.
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
Experimental testing in real world showed it's just a signing issue
in this specific case. The events passed to wayland clients scroll
in correct direction.
With that all the actions are implemented just like on X11.
There are two not yet implemented differences:
* hide splash window when clicking it
* replay event on special window
Implemented in the ForwardEventFilter: before forwarding the event
to the window we check whether a modifier is pressed and perform the
wheel command.
Possible improvements: each axis event triggers the same change, there
is no adjusted scaling.
This change implements the mouse command for modifier (alt/meta) plus
click in InputRedirection so that it also works on Wayland.
Modifier plus mouse wheel is not implemented yet.
For easier code in Options a new method is added which provides the
configured modifier as a Qt::KeyboardModifier instead of a Qt::Key code.
Test case is added which simulates all variants of modifiers plus
supported mouse buttons to trigger move.
So far the key handler in the InternalWindowEventFilter used the
PointerInputRedirection's internal window. This had the result that
key events were only delivered to an internal window if the window
was under the cursor.
This change tries sending the event to the latest created and visible
window. Thus e.g. with nested context menus it goes to the current
sub menu as expected. The return value of sendEvent is used to filter
out the event.
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.
So far the area based edges connected directly to global pointer pos
changed in InputRedirection. This didn't allow proper checking whether
the edge was triggered (e.g. missing timestamp).
This change merges the functionality into the new input filter mechanism.
There is now a dedicated input filter for screen edges, installed after
lock screen and before effects. It always passes events on, but also passes
all events through ScreenEdges to handle the activation. As it's installed
after the lock screen filter we don't need to check for screen locked any
more.
The code is now similar strucutured to the existing X11 based variants
and maybe will allow to also merge the X11 variant with the new one.
The logic should not be tied to whether libinput is used. It's relevant
for all Wayland backends whether they use libinput or not.
In addition this should generate a pointer motion event, so that proper
processing can take place and we get proper pointer enter events.
If the pointer is warped the position change should be treated like
a change coming from the input device. Our normal processing should
take place.
A problem in this case is the timestamp to pass to the wayland server.
Normally our timestamps come from the backend/libinput and we don't
know the next one. As an intermediate solution we just use the last
timestamp on the seat. In future a solution could be to not use the
backend's timestamp at all, but have our own timestamp handling.
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
InputRedirection connects to lockStateChanged to udate the current
pointer window. This way we can ensure that the current pointer
surface gets reset as soon as the screen locks (c.f. the expect
fail in the autotest) and also that it restores to the surface under
the mouse once the screen is unlocked.
The relevant code was not yet lock screen aware and performed an
early exit. Part of the code was fine, e.g. findToplevel is lock
screen aware. So this change adjusts the methods for updating the
internal window and decoration to be lock screen aware, that is they
get reset. With that updatePointerWindow is also lock screen aware.
Thus the LockScreenFilter can also use updatePointerWindow just like
the normal handling and does not need to reimplement parts of it. As
it now relies on other code being correct it has an additional check
to verify that the current pointer surface is a surface which is allowed
to get events. If it isn't the events are not forwarded.
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.
If the screen is locked and no lock screen is shown yet we unset
the focused keyboard surface on key event. Similar we restore when
screen is unlocked.
This should hopefully fix the broken lockscreen unit test which hits
the special condition as the greeter doesn't show up on build.kde.org.
