Summary:
When a shell client got mapped, unmapped and mapped again we emitted
the shellClientAdded signal in WaylandServer again. This resulted in
e.g. Workspace, EffectsHandler, etc. to start managing the window again.
This can be a reason for problems we see with such windows like the
Plasma panel dialog when opened the second time.
Test Plan:
Needs extensive testing on real world system as that changes
behavior now.
Reviewers: #kwin, #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D1784
Summary:
The method xRenderBlendPicture created a static XRenderPicture on
first usage. To cleanup a XRenderPicture an xcb_connection_t* is needed.
As it's static the cleanup happens on exit handler and at that time Qt
already destroyed the xcb_connection_t*. With a certain chance this will
crash.
To expose the problem a Q_ASSERT(qApp) is added in the destructor of
XRenderPicture. Using xrenderBlendPicture() will hit this assert on
application exit. This is demonstrated by the added auto test.
The actual fix to the problem is moving the static variable out of
the method and introduce a global cleanup method just like the init
method. This is now called from Workspace dtor, so before application
goes down.
CCBUG: 363251
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1731
Summary:
This ensures that resizing a panel updates the client area. On X11 there
is an event when the struts change, but on Wayland the struts are implied
from window type (panel) and the panel behavior, so we need to trigger it
manually.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1811
Summary:
The implementation was broken as it transformed the QRects into QRegions,
subtracted the geometries and took the bounding rect again. In several
setups this could result in the strut getting ignored.
This change improves the calculation of the struts by creating a QMargin
which describes the area which needs to be subtracted from a screen rect.
The QMargin is only adjusted for the edge the window borders. We can
assume that a window with a strut needs to border a screen on Wayland.
With this change we are also able to support panels between screens.
On Wayland a panel placed on the right of a left screen affects the
maximization area of the left screen, but does not affect the overall
workarea.
CCBUG: 167852
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1803
Summary:
From the famous category: "How could that code ever have worked".
Maximized state changes were never passed to window decorations. For
X11 windows the decoration updated the state nevertheless, for Wayland
windows the state did not get updated, thus a maximized window had
borders and was shown with a not maximized button.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1805
The added test exposes the problem that a shell surface might request
being maximized and then provide an incorrectly sized buffer. In this
case the ShellClient is incorrectly considered as maximized.
I don't have a good idea how to address this yet, but still publish
the test case exposing the problem.
Summary:
So far destroyWindowManagementInterface was only called when the
ShellClient got unmapped. But it's possible (although not recommended)
to just destroy the Surface without prior unmapping. In that case the
PlasmaWindow got leaked.
This change addresses this problem by always calling
destroyWindowManagementInterface from ShellClient::destroyClient.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1762
Summary:
If a PlasmaShellSurface is a Desktop, a Panel or an OSD it implies
that the window is on all desktop. So let's set it like that.
Test Plan: Auto test added and also confirmed by manual testing
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1747
Summary:
We don't want external processes to know anything about the lock screen
windows. Especially we don't want them to be able to request close on
them.
Thus better never show thus windows to them.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1760
Summary:
For some windows we don't want to create a PlasmaWindow. Not all
ShellClients are something the outside world should see. This change
introduces the first restrictions:
* KWin internal windows are hidden
* transients not accepting focus are hidden
The latter case doesn't work though if the Surface is mapped prior
to creating the shell surface. In such a situation it's racy as KWin
handles the create surface request before we get the setTransient
request. This is difficult to handle as we do want to react quickly.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1759
OpenGL/EGL doesn't work on build.kde.org. Because of that the
kscreenlocker_greet aborts on startup and we cannot really test whether
it works on build.kde.org. E.g. we never actually see the window.
This change just makes sure that QMLSCENE_DEVICE=softwarecontext is
passed to the greeter in the LockScreenTest. Hopefully that fixes it
on build.kde.org.
The new added test case verifies a few cases in which a PlasmaWindow
should or should not be created or destroyed.
Some cases are clearly wrong and are marked with expect_fail.
This test mocks part of KWin::Udev, udev and libinput. The test itself
is still rather limited and only verifies whether libinput is valid or
not and that assignSeat works. Most of the interaction is not yet tested,
though to a large degree doesn't make sense and should be rather tested
in the context of LibInput::Connection.
The test case sets up apol's screen setup and the panel as described
in the attachements in bug 363804. As the test shows the panel's strut
is incorrectly ignored.
CCBUG: 363804
This new test includes everything used in events.cpp to the mocked
functionality of libinput. Only key event is implemented so far, the
referenced pointer and touch functions are mocked with default values.
The test verifies that a KeyEvent gets created and the key press/release
works as expected.
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
This reverts commit abe582c27d.
To explain: the test uses a mocked implementation of libinput. Because
of that it must not link against libinput. The whole idea is to not link
libinput.
So I'm reverting the addition of libinput to linkage. I don't know the
build error, if it gets presented to me, I'll fix it properly without
having to add a linkage to libinput.
Summary:
Device has a static QVector<Device*> into which each created Device
is added and provides a static method to match a libinput_device* to
the already created Device.
This can be used by the the libinput Event class wrapper to properly
reference the Device the event is for.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1665
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
It's currently failing on build.kde.org. I'm not able to reproduce the
failure localy so I can only interpret the failure. The failure looks
like a window is still present in the next executed test case thus
breaking the positioning.
This change ensures that the window is properly gone before going into
the next test case.
Summary:
The usage of libinput is completely mocked. The test covers all the
constant properties read by Device.
There are some features which are not yet tested:
* alphaNumericKeyboard
* supportedButtons
* enabled
The setters for leftHanded and pointerAcceleration are also covered
including the variants where it can fail.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1648
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 delay to next cycle dance is needed for Aurorae. Maximizing a
window can result in the decoration being destroyed, in which case
QtQuick can trigger a crash.
A test case is added to simulate the situation and ensure that maximize
still works also after the change.
BUG: 362772
FIXED-IN: 5.6.5
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1586
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
The Scripted and PluginEffectLoader perform locating all effects which
are to be loaded in a thread. When the EffectLoader gets cleared so far
the query did not get canceled. This resulted in effects maybe getting
loaded.
This problems shows on build.kde.org if the test is too fast and tears
down the Effect system while effects are still being queried.
Reviewed-By: David Edmundson
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
Removes a diversion between X11 and Wayland. The base class Platform
creates an instance of class Edge with plugin implementations being
able to create a different type.
The X11StandalonePlugin does that and creates a WindowBasedEdge. For
this the implementation of WindowBasedEdge is moved from screenedges
into the plugin.
Unfortunately an ifdef is needed to make the screenedge test still
work as expected. This should be improved in future, e.g. have a good
way to load the platform plugin from the tests.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1419
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
By moving XRandrScreens the creation of screens gets simplified a lot
as there is no need to have windowing system specific init code. It all
just goes through the platform.
This also marks the point where the first X11 specific code is removed
from kwin_wayland.
Reviewers: #plasma, sebas
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1355
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)
