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:
When triggering a move resize all following pointer events are grabbed
by KWin itself. Thus the correct behavior is to informe the client about
it and send a pointer leave.
This ensures that after the move resize ended the pointer gets a new
enter. By sending anew pointer enter the position gets updated to the
new position which so far did not happen and the client generated events
on the wrong position.
BUG: 371573
FIXED-IN: 5.8.3
Reviewers: #kwin, #plasma_on_wayland, broulik
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3154
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:
The raw pointer button events intercepted in the XInput2 input filter
get sent through the Platform to the PointerInputRedirection. This
makes the PointerInputRedirection track the pointer button state and
emit the signals for button changed and axis changed.
These signals are used by the modifier-only shortcut detection to
determine whether the shortcut should trigger.
On X11 the "normal" input handling doesn't use the InputRedirection
and the emitted signals are not consumed by anything else. As
PointerInputRedirection is not inited the events are not forwarded
to the input filter, thus won't be processed by other parts and
won't interfere with the normal event processing on X11.
Given that it also doesn't matter that the input filter does not
apply the left-handed setting. The internal tracking will have a
wrong mouse button, but nothing is going to do decisions based on
the value of the pressed mouse button. For the moment all we are
interested in is that a button is pressed.
Test Plan:
Pressed meta, clicked, scrolled, released meta: launcher
did not open. Pressed meta, released meta: launcher opened
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2506
BUG: 367730
Summary:
For Xwayland windows we observed that passing pointer focus to another
window does not trigger proper leave events on X. Which results in e.g.
tooltip windows to show after the pointer moved to a completely
different position on a completely different surface.
This is a bug in Xwayland which will be fixed in 1.19 (already fixed in
master). Given that there is a runtime version check. Although it's fixed
in Xwayland master it's worth to carry a workaround.
To circumvent this problem KWin warps the xcb pointer to 0/0 whever an
X window loses pointer focus. That way the X window gets a proper leave
through the X protocol.
This created a problem though: when giving focus back to the X window it
started to warp the pointer for maximized windows as KWin got pointer
motion events through the X11 event filter for positions on the window
decoration. These are passed into the screen edge filter which pushes
the pointer back and warps our Wayland pointer. To solve this problem
KWin no longer performs any actions for pointer motion in the X11 event
filter if not on X11. The event filter needs to be reworked and most of
it should be moved into the Platform API, if possible.
Test Plan:
Reproduced situations where one could see that pointer updates
don't trigger leave. E.g. going from a highlighted window to the decoration.
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2531
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
So far KWin's pointer surface enter handling was:
1. update fouced surface
2. update the global position
On client side this resulted in:
1. Enter with incorrect coordinates
2. move event to correct coordinate
With QtWayland this results in the case of multiple surfaces in one
application that Qt doesn't properly process the enter event and the
Window never getting pointer focus and not reacting on any pointer
input events.
The root problem is that the KWayland server API is not ideal for
supporting this situation. There is an API call for setting the global
position (which causes a pointer motion for the focused surface) and
an API call to update the focused surface. But a combination for both
is (still) missing.
This change addresses the problem by first unsetting the entered surface,
then updating the global position and afterwards setting the new surface.
Thus the position is correct. While this needs to be made better in
KWayland, this is an urgency bug fix to get the behavior correct and thus
first working around the API deficit and not first extending in KWayland.
Reviewed-By: bshah
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:
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:
This ensures that QWindow::setMask works for KWin internal windows.
Without KWin sends all pointer events to the QWindow, even if the
mask says it shouldn't get events.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1509
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
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.
Updating the focused pointer surface results in the cursor to change.
The CursorImage needs the current focused window to evaluate which cursor
to use, though. Thus we need to make sure that the window reflects the
current state before updating the seat.
The WaylandCursorTheme emits a signal whenever it reloads the theme.
This is used by CursorImage to clear the cache and reload decoration
and fallback cursor.
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 ).
The mapping is slightly inspired by the mapping in QtWayland.
But the mapping in QtWayland seems wrong. E.g. there is a linux kernel
button called BTN_BACK which is not mapped to Qt::BackButton.
Anyway we are not really interested in the mapping being 100 % correct
for the case in KWin. KWin internally uses only very few mouse buttons
and all others are only relevant to figure out whether buttons are
pressed. The button code itself is passed to the seat with the native
code.
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.
