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:
Instead of having the Application invoke initOutputs after creating
the Screens, we can just connect to the signal emitted there.
This allows to make initOutputs a private, WaylandServer internal
method.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1482
Without the /dev/dri/card0 mesa fails to initialize egl and the test
fails. In order to silence the failure till the system provides the
device file, we better skip the test.
A nullptr crash in that case is fixed in WaylandServer tear-down.
Summary: Move/Resize and Strut tests Wayland tests are affected.
Test Plan: Successful compilation when XCB_ICCCM is not found
Reviewers: graesslin
Reviewed By: graesslin
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1476
Summary:
The cursor position is the reference KWin uses while moving a window.
If we don't warp the cursor position the window "jumps" to the cursor
position on first movement.
For requests triggered by the client (e.g. widget style) this does not
matter as the cursor is at the correct position. But for tools such as
task bars we should ensure the cursor is at the right pos.
Reviewers: #plasma, hein
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1421
Summary:
If a window has an invalid size the decoration also has an invalid
size. This results in the texture used by the
SceneOpenGLDecorationRenderer to be invalid and being reset to null.
Of course we shouldn't try to use this texture to render to.
The change comes with a test case to simulate the situation. We cannot
simulate it with Wayland clients as the geometry can never be empty.
Thus we create an X11 client, resize it to an empty size and unmap it.
This is the first integration test case which creates an X11 Client!
It's also a test case which needs the OpenGL compositor. This will most
likely not work on build.kde.org yet - we need to see what to do about
it. Will need adjustments to get it at least skip on build.kde.org.
BUG: 361551
FIXED-IN: 5.6.3
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1383
Summary:
Mostly meant for multi-screen setups: we don't want that a strut set on
a window on screen 0 results in screen 1 completely being excluded. Even
if that's strictly seen a client bug, it's better to just ignore the
strut from KWin's side.
The sanity check is implemented in Client::adjustedClientArea.
From a pure standard point of view this change is a EWMH violation and
thus can cause regressions: struts by clients no longer working.
A test case for struts is added, including some invalid combinations
whose strut is ignored with this change.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1386
Summary:
Source code reorganization:
The base class AbstractBackend got renamed to Platform, thus the
"backends" are "platforms" now. As they are plugins they should go
together with other KWin plugins which are nowadays in the folder
plugins.
So new location is plugins/platforms/
Reviewers: #plasma, sebas
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1353
Summary:
This is the first change in a refactoring series. The aim is to:
* rename AbstractBackend to Platform
* move backends/ to plugins/platforms/
* don't bind platforms to Wayland only
* provide a platform plugin for "normal" X11
* share more code between X11 and Wayland
This change moves the platform/backend from waylandServer to Application.
The init of the plugin happens directly in the Application from the
KPluginMetaData. There is no need to externally init it and set the
parent.
WaylandServer::backend() currently just delegates to
kwinApp()->platform(), the idea is to drop this method completely.
The test infrastructure is also adjusted to this change.
Test Plan: kwin_wayland still works, all tests pass
Reviewers: #plasma, sebas
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1331
On build.kde.org we cannot use the breeze cursor theme. Instead we have
DMZ-White (debian package dmz-cursor-theme).
This change adjusts the PointerInput test to enforce DMZ-White and uses
SizeAllCursor instead of OpenHandCursor as that one seems to be missing
in that theme.
Hopefully with these changes the test starts to pass on build.kde.org.
Summary:
A user shouldn't be able to manually move/resize a desktop window or
a panel. So far this wasn't ensured.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1155
Summary:
The idea behind the debugging console is to have a feature comparable
to xprop and xwininfo just for Wayland. We cannot have command line
utils as that violates the security restrictions, thus it needs to be
exposed directly in KWin.
The debugging console is invoked through DBus:
qdbus org.kde.KWin /KWin showDebugConsole
This opens a window with a tree view. The DebugConsoleModel which is
used by the tree view groups all windows into four categories:
* x11 clients (that is Workspace::clientList() and Workspace::desktopList())
* x11 unmanaged (Workspace::unmanagedList())
* wayland shell clients (WaylandServer::clients())
* wayland internal clients (KWin's own QWindows - WaylandServer::internalClients())
Each window is a child to one of the four categories. Each window itself
has all it's QProperties exposed as children.
This allows to properly inspect KWin's internal knowledge for windows and
should make it easier to investigate problems. E.g. what's a window's
geometry, what's it's window type and so on.
The debugging console is intended as a developer tool and not expected to
be used by users. That's why it's invokation is rather hidden. Due to
the fact that it's internal to KWin it results in:
* no window decoration
* stealing keyboard focus
* no way to resize, close, move from KWin side
* rendered above all other windows
There is a dedicated close button to get rid of it again. While the
console is shown it's hardly possible to interact with the system in
a normal way anymore. This is something which might be improved in
future.
At the moment the model is able to update when windows are added/removed,
but not yet when a property changes. Due to the lack of interaction with
the existing system, that's not a high priority at the moment, but can
be added in future.
Reviewers: #plasma
Differential Revision: https://phabricator.kde.org/D1146
A transient window should always be visible on the current screen.
This change ensures that a transient is always placed in a way that
the transient window is visible on the screen ignoring the transient
offset hint if it has to be.
Unfortunately QtWayland doesn't set the transient hint correctly:
a sub menu is a transient to the main window and not to the parent
menu resulting in quite off positioned menus, see:
https://bugreports.qt.io/browse/QTBUG-51640
Need to add client pos to the transient's position. The offset is
relative to the parent surface, but the client doesn't know about the
size of the decoration, thus KWin needs to add it.
Test creates windows and transients for it and verifies the position.
For decorated windows the position is currently broken as it does not
consider the adjusted client position.
Try to fix test on CI system. With neither a config nor the env variables
the cursor selection falls back to the default cursor theme, which might
not contain the cursors we need.
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.
The test case verifies that setting an override cursor during mouse
interception works and that it's also possible to change it. When
ending mouse interception the cursor image should be adjusted again.
The test shows that when mouse interception starts KWin should send
a pointer leave event to the current focused window and similar needs
to handle the stop of mouse interception.
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.
This test case verifies that the cursor image and hot spot changes
correctly when focusing a window, changes when damaged and hides.
Test shows that when focusing a window the cursor image is not
removed, neither that unfocus sets back to fallback cursor properly.
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.
Canceling the animation in the animationEnded handler triggers a crash.
This is due to multiple lists being iterated and manipulated at the same
time.
This adds a test case which simulates the crashy situation.
REVIEW: 126975
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.
This makes QCursor::pos and QCursor::setPos function correctly. KWin
actually wouldn't need it as KWin has the KWin::Cursor replacement, but
it allows Qt internal API to have it function correctly and also the
zoom effect does use QCursor::setPos.
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.
The MoveResizeWindowTest is extended by a test case to verify that
the move only ends once all mouse buttons are released. So far this
is not yet the case as KWin has an incorrect mapping of buttons to
Qt::MouseButtons.
So far KSldApp was always either in state AcquiringLock or Unlocked
during the tests. Due to a fix in WaylandServer it now can also enter
the Locked state. But this is timing related and also depends on whether
the greeter works at all. E.g. on build.kde.org the greeter fails to
start, so it never enters the Locked state.
The adjusted test now considers that the state might have changed to
Locked and expects one additional signal to be emitted.
CI system is adjusted, so that OpenGL should work. At least latest
run didn't show the EGL warnings in the lock screen test. So let's
try to enable again. It's possible that this fails horribly. If that's
the case I'll revert again.
The dontCrashGlxgearsTest is kept on QPainter as locally it crashes
on teardown (needs fixing).
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.
The test removes the second screen while the cursor is on it. This
should warp the pointer to the center of first screen and trigger
a focus enter event.
As can be seen by the expect failures currently it's bound to libinput
and also doesn't process the event as if it were a pointer event.
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 warping a pointer through Cursor::setPos it should be processed
just like any other pointer event. It should generate enter/leave event,
create motion events, etc. This is currently not the case as the test
shows.
A new test case which ensures that when stacking order changes the
pointer focus gets re-evaluated and updated. I was positively surprised
to notice that this already works.
Noticed two other problems while writing the test case:
* warping pointer does not re-evaluate the pointer pos
* deleting a ShellSurface (client) does not destroy the ShellClient (server)
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 test creates a QRasterWindow which through KWin's internal QPA
is considered an internal window. In the test methods we simulate
various pointer events (enter/leave, press/release, wheel).
First test case is whether wheel events are forwarded correctly.
From the code it seems to me like up/down is inversed. Needs manual
testing.
As this requires working decorations it's possible that this test
will fail on build.kde.org.
Interesting approach I would not have expected to work. A dummy Effect
class is created in the test and an instance is passed to
EffectsHandler's startMouseInterception. It doesn't verify whether it's
an Effect it knows or has created, so it's totally happy with the dummy.
It shows that motion and press/release are passed to the Effect when
screen is not locked and doesn't while the screen is locked.
On the CI system our tests failed due to the greeter failing to start
due to OpenGL problems. This was because we waited for a window to show
which never happened. Thus the test failed.
This change makes use of the new lockStateChanged signal to determine
when the screen gets locked/unlocked.
It's still possible that the test fails as I'm not able to reproduce
the failure condition on the CI system.
First test case is to ensure that pointer motion events trigger a
leave event on the surface the pointer is on.
The test case shows errors in the input handling.
More tests need to be added.
Trigger quick tiling by moving the window. For moving the window only
keyboard keys are used.
The test experienced some problems with the Outline triggering crashes.
To work around them the test disables the Outline by specifying an
invalid configuration.
Ensures that all Wayland objects are destroyed and the cleanup handling
is performed before tearing down the Compositor. This fixes for example
a crash if a Surface with a Shadow is still around at tear down.
WaitForFinished blocks our main thread, but Xwayland wants to talk
to Wayland and blocks as well. So let's ensure events are processed
while terminating Xwayland.
Some effects do X11 calls in their cleanup code through external
libraries (e.g. KSelectionOwner). As we cannot control that we need
to ensure the effects are unloaded prior to destroying the Xwayland
connection.
We need to destroy the ClientConnections we create. Also we need
to disconnect our Xwayland error handling before destroying it, otherwise
it would trigger the abort for crashing Xwayland.
During Compositor tear down Xwayland is already destroyed. Thus it
doesn't make sense to try to delete the support properties: either
it freezes in xcb or it crashes because the connection is null.
At the same time we also ensure that the connection internally is
reset to null. Note: the one in kwinglobals.h caches and could cause
use-after-free errors. Any tear-down code must be migrated to
kwinApp()->x11Connection().
We need to destroy the compositor after Xwayland terminated and after
the internal Wayland connection is destroyed. This means when destroying
the Workspace we may no longer destroy the Compositor at the same time.
Also we need to ensure that other tear down functionality doesn't call
into the no longer existing internal client connection.
With this change kwin doesn't crash when exiting with Wayland and/or
X11 windows still open.
Methods are no longer virtual. The only x11 specific usage in these
methods (resizeInc) is replaced by a virtual method. Default resize
increments is QSize(1,1) for AbstractClient.
Don't emit both geometryShapeChanged and geometryChanged: the one
is set up to call the other.
Also adjust tests because maximize changes triggers too many geometry
changed signals.
Method no longer virtual and only implemented in AbstractClient.
The implementaton works in a generic way nowadyas.
Added an autotest for the basic packTo behavior for packing against
a screen border. Packing towards other clients still needs adjustments
in the Placement code.
The signals operate on AbstractClient nowadays, so we can have one
implementation for both Client and ShellClient.
Only X specific connections are only done for Client.
So far only moving through useractions menu is possible and only through
cursor control (mouse events are lost).
A basic first autotest is added to validate the moving of Windows.
The problem we had was closing a glxgears through an Aurorae theme
crashed KWin inside QtQuick.
This test case simulates the sequence:
1. starts glxgears
2. wait till we have a Client for it
3. send mouse move to guessed close button position
4. send mouse press/release at that position
5. verify the window is closed
6. verify glxgears exits
With the given commit reverted this crashes, with it in place it passes.
Please note: on CI it might fail as glxgears is not yet installed. [1]
Also we cannot enforce using Aurorae from the test yet, though on
the CI system it should get picked automatically as no other deco
plugin should be installed.
[1] Sysadmin ticket already created
