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.
-use qstringliteral only when necessary (i.e. not in concat or comparison)
-use qbytearray instead of qstring when dealing with latin1 input and output (glplatform)
-use qstringref to extract numbers from strings (glplatform)
-define qt_use_qstringbuilder to optimize all string concatenations
-anidata: use ctor init lists, add windowType member initialization
REVIEW: 125933
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.
