yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/autotests/integration/kwin_wayland_test.cpp

203 lines
6.2 KiB
C++
Raw Normal View History

Prettify license headers
2020-08-02 22:22:19 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2015 Martin Gräßlin <mgraesslin@kde.org>
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
#include "kwin_wayland_test.h"
Make source code more relocatable Occasionally, I see complaints about the file organization of kwin, which is fair enough. This change makes the source code more relocatable by removing relative paths from includes. CMAKE_CURRENT_SOURCE_DIR was added to the interface include directories of kwin library. This means that as long as you link against kwin target, the real location of the source code of the library doesn't matter. With autotests, things are not as convenient as with kwin target. Some tests use cpp files from kwin core. If we move all source code in a src/ directory, they will need to be adjusted, but mostly only in build scripts.
2021-02-09 18:18:36 +00:00
Make backends part of libkwin Platform backends are provided as plugins. This is great for extensibility, but the disadvantages of this design outweigh the benefits. The number of backends will be limited, it's safe to say that we will have to maintain three backends for many years to come - kms/drm, virtual, and wayland. The plugin system adds unnecessary complexity. Startup logic is affected too. At the moment, platform backends provide the session object, which is awkward as it starts adding dependencies between backends. It will be nicer if the session is created depending on the loaded session type. In some cases, wayland code needs to talk to the backend directly, e.g. for drm leasing, etc. With the plugin architecture it's hard to do that. Not impossible though, we can approach it as in Qt 6, but it's still harder than linking the code directly. Of course, the main disadvantage of shipping backends in a lib is that you will need to patch kwin if you need a custom platform, however such cases will be rare. Despite that disadvantage, I still think that it's a step in the right direction where the goal is to have multi-purpose backends and other reusable components of kwin. The legacy X11 standalone platform is linked directly to kwin_x11 executable, while the remaining backends are linked to libkwin.
2022-07-22 14:22:09 +00:00
#include "backends/virtual/virtual_backend.h"
Make source code more relocatable Occasionally, I see complaints about the file organization of kwin, which is fair enough. This change makes the source code more relocatable by removing relative paths from includes. CMAKE_CURRENT_SOURCE_DIR was added to the interface include directories of kwin library. This means that as long as you link against kwin target, the real location of the source code of the library doesn't matter. With autotests, things are not as convenient as with kwin target. Some tests use cpp files from kwin core. If we move all source code in a src/ directory, they will need to be adjusted, but mostly only in build scripts.
2021-02-09 18:18:36 +00:00
#include "composite.h"
#include "effects.h"
#include "inputmethod.h"
#include "platform.h"
#include "pluginmanager.h"
Move ownership of Session to Application The Session can be useful not only to the platform backend but also input backends and for things such as vt switching, etc. Therefore it's better to have the Application own the Session.
2022-07-23 13:22:54 +00:00
#include "session.h"
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
#include "utils/xcbutils.h"
Make source code more relocatable Occasionally, I see complaints about the file organization of kwin, which is fair enough. This change makes the source code more relocatable by removing relative paths from includes. CMAKE_CURRENT_SOURCE_DIR was added to the interface include directories of kwin library. This means that as long as you link against kwin target, the real location of the source code of the library doesn't matter. With autotests, things are not as convenient as with kwin target. Some tests use cpp files from kwin core. If we move all source code in a src/ directory, they will need to be adjusted, but mostly only in build scripts.
2021-02-09 18:18:36 +00:00
#include "wayland_server.h"
#include "workspace.h"
src/xwl -> src/xwayland It makes naming more consistent, we use "wayland" more frequently than "wl".
2022-04-22 10:09:02 +00:00
#include "xwayland/xwayland.h"
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
Provide the platform() -> AbstractBackend* in KWin::Application 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
2016-04-06 15:30:00 +00:00
#include <KPluginMetaData>
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
#include <QAbstractEventDispatcher>
#include <QPluginLoader>
#include <QSocketNotifier>
#include <QThread>
#include <QtConcurrentRun>
// system
#include <iostream>
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
#include <sys/socket.h>
#include <unistd.h>
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
Bundle QPA plugin directly On wayland, we know we're always going to load our internal QPA. Instead of shipping a plugin and loading it dynamically we can use Qt static plugins. This should result in slightly faster load times, but also reduce the number of moving pieces for kwin. This also prevents anyone outside kwin loading our QPA which wouldn't have made any sense and just crashed.
2020-11-20 14:28:47 +00:00
Q_IMPORT_PLUGIN(KWinIntegrationPlugin)
wayland: Link statically KGlobalAccel integration plugin Without the KGlobalAccel integration plugin, Wayland experience will be negatively affected. Therefore it makes little sense to load it at run- time.
2020-11-21 10:16:59 +00:00
Q_IMPORT_PLUGIN(KGlobalAccelImpl)
wayland: Link statically KWindowSystem integration plugin Without the KWindowSystem integration plugin, Wayland experience will be negatively affected because windows created by kwin itself won't behave as desired. Therefore it makes little sense to load this plugin at runtime.
2020-11-21 10:22:48 +00:00
Q_IMPORT_PLUGIN(KWindowSystemKWinPlugin)
wayland: Link statically against KIdleTime integration plugin The main motivation behind this change is to improve startup time. The Poller class was renamed to avoid potential name conflicts in the future.
2020-11-21 10:36:49 +00:00
Q_IMPORT_PLUGIN(KWinIdleTimePoller)
Bundle QPA plugin directly On wayland, we know we're always going to load our internal QPA. Instead of shipping a plugin and loading it dynamically we can use Qt static plugins. This should result in slightly faster load times, but also reduce the number of moving pieces for kwin. This also prevents anyone outside kwin loading our QPA which wouldn't have made any sense and just crashed.
2020-11-20 14:28:47 +00:00
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
namespace KWin
{
[autotests] Support Wayland Only in addition to XWayland The integrationTest function takes a new optional argument whether the test supports a Wayland Only mode. If that's the case the test is compiled twice, once (as always) as "foo" with XWayland support and once as "foo_waylandonly" without XWayland support. This way we can ensure that our code always supports both modes. The tests found multiple issues. At the moment fast running tests are sporadically crashing on tear down. This needs further investigation.
2017-09-30 14:35:52 +00:00
WaylandTestApplication::WaylandTestApplication(OperationMode mode, int &argc, char **argv)
Drop ApplicationWaylandAbstract We gain nothing with it. XCB setup logic in the Xwayland server has to be moved to the workspace layer anyway. For example, this move of responsibilities will be needed to support running more than just one instance of Xwayland. Architecture-wise, it would be cleaner too. Unfortunately, it breaks encapsulation of the Application, but this can be taken care later.
2022-07-15 07:15:54 +00:00
: Application(mode, argc, argv)
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
{
[autotest/integration] Enable test mode for QStandardPaths By enabling test mode for QStandardPath kglobalaccel doesn't modify the user's global shortcuts any more.
2016-10-05 11:21:33 +00:00
QStandardPaths::setTestModeEnabled(true);
Delete kglobalshortcutsrc before executing a test Summary: When running the complete test suite the ScriptedEffectsTest::testShortcuts registers the shortcut meta+shift+y. But GlobalShortcutsTest::testX11ClientShortcut also tries to use this shortcut for a window shortcut which fails if it is already registered. So when running the complete test suite it depends on the order of execution whether the GlobalShortcutsTest passes or not. Test should be clean - also the globalshortcuts. As the config is read from test directory anyway, we can delete the file prior to init of kglobalaccel. Test Plan: Run ctest, test did not fail anymore Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16932
2018-11-16 19:07:09 +00:00
// TODO: add a test move to kglobalaccel instead?
QFile{QStandardPaths::locate(QStandardPaths::ConfigLocation, QStringLiteral("kglobalshortcutsrc"))}.remove();
[autotests] Set breeze icon theme name in integration tests This is an attempt to get some tests failing on the CI due to not finding icons fixed. See T8082
2018-02-27 17:17:53 +00:00
QIcon::setThemeName(QStringLiteral("breeze"));
Use #cmakedefine01 for all KWIN_BUILD_* macros This ensures that we get a warning if the config header is not included instead of compiling the code as if it was disabled. Interestingly, some checks already used #if KWIN_BUILD_*, so those were generating -Wundef warnings when the feature is disabled. Commit 886173cab assumed that all those features were already 01, so this unbreaks the build if any of the features is disabled. Fixes: 886173cab ("Reduce ifdefs in Workspace::supportInformation()")
2022-02-28 18:58:35 +00:00
#if KWIN_BUILD_ACTIVITIES
[autotests/wayland] Disable KActivities in the tests Makes our tests time out, we're too fast in shutting down.
2015-12-18 15:40:52 +00:00
setUseKActivities(false);
#endif
Revert "[autotest] Let's dare enabling the OpenGL compositor in the tests" This reverts commit 5e21963a3b620a167d9319e992c79a56f19d5bfd. Unfortunately all tests failed on the CI system, so no GL yet :-(
2016-02-12 14:22:55 +00:00
qputenv("KWIN_COMPOSE", QByteArrayLiteral("Q"));
autotests: Fix kglobalaccel integration Starting with 48c3376927e5e9c13377bf3cfc8b0c411783e7f3 in kglobalaccel, KGlobalAccel won't work in desktop environments other than Plasma. We need to set XDG_CURRENT_DESKTOP=KDE to ensure that global shortcuts still work.
2021-05-05 06:15:17 +00:00
qputenv("XDG_CURRENT_DESKTOP", QByteArrayLiteral("KDE"));
Unset XKB_DEFAULT_* in tests to make tests better reproducable Summary: On one of my systems XKB_DEFAULT_LAYOUT is set to "de". This makes a few tests fail, e.g. pointer input and modifier only shortcuts. The reason is that those tests assume the xkb default layout behavior, that is how xkb functions without any layout being set. So having the env variable around influences the layout generation. To prevent this the environment variables are unset and thus a reproducable environment is created. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16737
2018-11-07 15:09:34 +00:00
qunsetenv("XKB_DEFAULT_RULES");
qunsetenv("XKB_DEFAULT_MODEL");
qunsetenv("XKB_DEFAULT_LAYOUT");
qunsetenv("XKB_DEFAULT_VARIANT");
qunsetenv("XKB_DEFAULT_OPTIONS");
Build platform plugins in correct sub directory of build dir Summary: This brings KWin a step closer to be run from build dir without having to install at all. The integration tests are adjusted so that the virtual platform is still found which makes the code be closer to what is used in normal kwin_wayland. Test Plan: ctest passes, manually verified correct plugin is loaded Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17388
2018-12-06 17:38:36 +00:00
autotests: Use Smart placement by default Many tests were written with the smart placement in mind and fail now because the default placement policy was changed to "centered"
2021-11-29 07:53:53 +00:00
auto config = KSharedConfig::openConfig(QString(), KConfig::SimpleConfig);
KConfigGroup windowsGroup = config->group("Windows");
windowsGroup.writeEntry("Placement", Placement::policyToString(Placement::Smart));
windowsGroup.sync();
setConfig(config);
Build platform plugins in correct sub directory of build dir Summary: This brings KWin a step closer to be run from build dir without having to install at all. The integration tests are adjusted so that the virtual platform is still found which makes the code be closer to what is used in normal kwin_wayland. Test Plan: ctest passes, manually verified correct plugin is loaded Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17388
2018-12-06 17:38:36 +00:00
const auto ownPath = libraryPaths().last();
removeLibraryPath(ownPath);
addLibraryPath(ownPath);
Move ownership of Session to Application The Session can be useful not only to the platform backend but also input backends and for things such as vt switching, etc. Therefore it's better to have the Application own the Session.
2022-07-23 13:22:54 +00:00
setSession(Session::create(Session::Type::Noop));
Make backends part of libkwin Platform backends are provided as plugins. This is great for extensibility, but the disadvantages of this design outweigh the benefits. The number of backends will be limited, it's safe to say that we will have to maintain three backends for many years to come - kms/drm, virtual, and wayland. The plugin system adds unnecessary complexity. Startup logic is affected too. At the moment, platform backends provide the session object, which is awkward as it starts adding dependencies between backends. It will be nicer if the session is created depending on the loaded session type. In some cases, wayland code needs to talk to the backend directly, e.g. for drm leasing, etc. With the plugin architecture it's hard to do that. Not impossible though, we can approach it as in Qt 6, but it's still harder than linking the code directly. Of course, the main disadvantage of shipping backends in a lib is that you will need to patch kwin if you need a custom platform, however such cases will be rare. Despite that disadvantage, I still think that it's a step in the right direction where the goal is to have multi-purpose backends and other reusable components of kwin. The legacy X11 standalone platform is linked directly to kwin_x11 executable, while the remaining backends are linked to libkwin.
2022-07-22 14:22:09 +00:00
setPlatform(std::make_unique<VirtualBackend>());
Provide the platform() -> AbstractBackend* in KWin::Application 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
2016-04-06 15:30:00 +00:00
WaylandServer::create(this);
[autotests] Use Xwayland class in WaylandTestApplication Summary: By using the new Xwayland class we can reduce code duplication. An abstract parent class is introduced, that allows interfacing with the Xwayland class from the test binaries. Test Plan: Autotests still pass. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D15022
2018-08-22 00:20:16 +00:00
setProcessStartupEnvironment(QProcessEnvironment::systemEnvironment());
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
}
WaylandTestApplication::~WaylandTestApplication()
{
Ensure the Compositor does not start during termination Summary: The SceneOpenGLES test was starting to randomly crash on my system. On investigation I observed that there was a graphics reset ("Attempting to reset compositing.") which triggered a delayed restart of the compositor. This even was only processed while waiting for XWayland to terminate. Which resulted in a crash in KWin::getXServerVersion as the xcb connection broke. It makes no sense to setup the compositor again during application shutdown. Thus the dtors set a flag that they are terminating the application and Compositor::setup is checking for it. Test Plan: Test no longer crashes, although it goes through the crashing path Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18015
2019-01-06 16:05:10 +00:00
setTerminating();
[wayland] Unload all effects prior to destroying Xwayland connection 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.
2015-11-12 10:29:56 +00:00
// need to unload all effects prior to destroying X connection as they might do X calls
[autotests/integration] Unload effects before destroying Workspace Brings in line with behavior in main_wayland.cpp and is needed as effects might call into Workspace during tear down.
2016-07-04 12:37:35 +00:00
// also before destroy Workspace, as effects might call into Workspace
[wayland] Unload all effects prior to destroying Xwayland connection 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.
2015-11-12 10:29:56 +00:00
if (effects) {
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
static_cast<EffectsHandlerImpl *>(effects)->unloadAllEffects();
[wayland] Unload all effects prior to destroying Xwayland connection 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.
2015-11-12 10:29:56 +00:00
}
Survive Xwayland crashes If the Xwayland process crashes, it will bring down the entire session together with itself. Obviously, we don't want that. At least, Wayland clients should survive the crash. This change refactors relevant X11 parts to handle Xwayland crashes in a less fatal way. In order to handle Xwayland crashes better, a pair of start() and stop() methods had been introduced in the Xwayland class to allow starting and stopping the Xwayland process at any moment. If we detect that the Xwayland process has crashed, we will immediately stop the Xwayland server, which in its turn will deactivate the socket notifier and destroy all connected X11 clients. Unfortunately, a couple of subtle changes in X11Client::releaseWindow() and Unmanaged::release() had to be made to ensure that we are left with a valid state after the Xwayland server has been stopped.
2020-07-20 08:07:08 +00:00
delete m_xwayland;
m_xwayland = nullptr;
Add all three VirtualInputDevices for autotests [3/6] Make autotests create fake input devices This commit adds back all three VirtualInputDevices for simulating keyboard, touch and pointer input events from autotests.
2022-02-26 08:22:31 +00:00
destroyVirtualInputDevices();
wayland: Terminate client connections before Workspace is destroyed Summary: When ShellClient tears down, it needs to access RuleBook in order to discard temporary rules. The problem is that WaylandServer outlives Workspace and therefore so does ShellClient. We can't guard against the case when RuleBook::self() is nullptr as it is vital to discard temporary rules. This change adjusts termination sequence so all shell clients are destroyed before Workspace(and thus RuleBook) is gone. ASAN output: ==19922==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000142060 at pc 0x7fbc0fb878bb bp 0x7ffd7d464520 sp 0x7ffd7d464518 READ of size 8 at 0x606000142060 thread T0 #0 0x7fbc0fb878ba in QList<KWin::Rules*>::detach() /usr/include/qt5/QtCore/qlist.h:172 #1 0x7fbc0fb8538d in QList<KWin::Rules*>::begin() /usr/include/qt5/QtCore/qlist.h:324 #2 0x7fbc0fb808b6 in KWin::RuleBook::discardUsed(KWin::AbstractClient*, bool) /home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.12/rules.cpp:1144 #3 0x7fbc0fe36e32 in KWin::ShellClient::destroyClient() /home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.12/shell_client.cpp:435 #4 0x7fbc0fe7a726 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (KWin::ShellClient::*)()>::call(void (KWin::ShellClient::*)(), KWin::ShellClient*, void**) /usr/include/qt5/QtCore/qobjectdefs_impl.h:152 #5 0x7fbc0fe784c3 in void QtPrivate::FunctionPointer<void (KWin::ShellClient::*)()>::call<QtPrivate::List<>, void>(void (KWin::ShellClient::*)(), KWin::ShellClient*, void**) /usr/include/qt5/QtCore/qobjectdefs_impl.h:185 #6 0x7fbc0fe74de9 in QtPrivate::QSlotObject<void (KWin::ShellClient::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (/home/jenkins/install-prefix/lib64/libkwin.so.5+0x1677de9) #7 0x7fbc04f27357 in QMetaObject::activate(QObject*, int, int, void**) (/usr/lib64/libQt5Core.so.5+0x2b3357) #8 0x7fbc074e1970 in KWayland::Server::Resource::unbound() /home/jenkins/workspace/Administration/Dependency Build Plasma kf5-qt5 SUSEQt5.12/kwayland/build/src/server/KF5WaylandServer_autogen/EWIEGA46WW/moc_resource.cpp:142 #9 0x7fbc0766b4b4 in KWayland::Server::Resource::Private::unbind(wl_resource*) /home/jenkins/workspace/Administration/Dependency Build Plasma kf5-qt5 SUSEQt5.12/kwayland/src/server/resource.cpp:68 #10 0x7fbc00bdc2ae (/usr/lib64/libwayland-server.so.0+0x92ae) #11 0x7fbc00bdc32f in wl_resource_destroy (/usr/lib64/libwayland-server.so.0+0x932f) #12 0x7fbc0766b53f in KWayland::Server::Resource::Private::resourceDestroyedCallback(wl_client*, wl_resource*) /home/jenkins/workspace/Administration/Dependency Build Plasma kf5-qt5 SUSEQt5.12/kwayland/src/server/resource.cpp:76 #13 0x7fbbff481d8c (/usr/lib64/libffi.so.7+0x6d8c) #14 0x7fbbff481179 (/usr/lib64/libffi.so.7+0x6179) #15 0x7fbc00bdfa5f (/usr/lib64/libwayland-server.so.0+0xca5f) #16 0x7fbc00bdc6d1 (/usr/lib64/libwayland-server.so.0+0x96d1) #17 0x7fbc00bddc71 in wl_event_loop_dispatch (/usr/lib64/libwayland-server.so.0+0xac71) #18 0x7fbc07541e50 in KWayland::Server::Display::Private::dispatch() /home/jenkins/workspace/Administration/Dependency Build Plasma kf5-qt5 SUSEQt5.12/kwayland/src/server/display.cpp:148 #19 0x7fbc075432de in KWayland::Server::Display::dispatchEvents(int) /home/jenkins/workspace/Administration/Dependency Build Plasma kf5-qt5 SUSEQt5.12/kwayland/src/server/display.cpp:220 #20 0x7fbc0fe864ca in KWin::WaylandServer::dispatch() /home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.12/wayland_server.cpp:616 #21 0x451ce0 in KWin::WaylandTestApplication::~WaylandTestApplication() /home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.12/autotests/integration/kwin_wayland_test.cpp:91 #22 0x42faa1 in main /home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.12/autotests/integration/globalshortcuts_test.cpp:381 #23 0x7fbc04796bca in __libc_start_main (/lib64/libc.so.6+0x26bca) #24 0x413ea9 in _start (/home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.12/build/bin/testGlobalShortcuts+0x413ea9) Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22821
2019-07-30 08:40:18 +00:00
destroyWorkspace();
Rework input method teardown logic Explicitly destroy input method rather than wait for the input method connection to be destroyed by WaylandServer, it's less error prone. BUG: 443603
2021-10-14 07:40:08 +00:00
destroyInputMethod();
[wayland] Improve tear-down to not crash if X11 applications are still around 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.
2015-11-10 07:52:40 +00:00
destroyCompositor();
autotests: Fix ASAN issues Currently, InputRedirection is not destroyed before waylandServer(), unlike in kwin_wayland, which causes some null dereferencing.
2021-10-14 19:03:39 +00:00
destroyInput();
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
}
Add all three VirtualInputDevices for autotests [3/6] Make autotests create fake input devices This commit adds back all three VirtualInputDevices for simulating keyboard, touch and pointer input events from autotests.
2022-02-26 08:22:31 +00:00
void WaylandTestApplication::createVirtualInputDevices()
{
m_virtualKeyboard.reset(new Test::VirtualInputDevice());
m_virtualKeyboard->setName(QStringLiteral("Virtual Keyboard 1"));
m_virtualKeyboard->setKeyboard(true);
m_virtualPointer.reset(new Test::VirtualInputDevice());
m_virtualPointer->setName(QStringLiteral("Virtual Pointer 1"));
m_virtualPointer->setPointer(true);
m_virtualTouch.reset(new Test::VirtualInputDevice());
m_virtualTouch->setName(QStringLiteral("Virtual Touch 1"));
m_virtualTouch->setTouch(true);
input()->addInputDevice(m_virtualPointer.get());
input()->addInputDevice(m_virtualTouch.get());
input()->addInputDevice(m_virtualKeyboard.get());
}
void WaylandTestApplication::destroyVirtualInputDevices()
{
input()->removeInputDevice(m_virtualPointer.get());
input()->removeInputDevice(m_virtualTouch.get());
input()->removeInputDevice(m_virtualKeyboard.get());
}
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
void WaylandTestApplication::performStartup()
{
Fix size restore upon keyboard close in XdgSurfaceClient in XdgSurfaceClient setFrameGeometry is async, so we can't rely on it having the final value immediately. make setVirtualKeyboardGeometry a virtual. in the implementation on setVirtualKeyboardGeometry use requestedFrameGeometry() instead of frameGeometry()
2020-09-01 08:58:46 +00:00
if (!m_inputMethodServerToStart.isEmpty()) {
move InputMethod singleton to Application
2022-07-20 10:14:27 +00:00
createInputMethod();
Fix size restore upon keyboard close in XdgSurfaceClient in XdgSurfaceClient setFrameGeometry is async, so we can't rely on it having the final value immediately. make setVirtualKeyboardGeometry a virtual. in the implementation on setVirtualKeyboardGeometry use requestedFrameGeometry() instead of frameGeometry()
2020-09-01 08:58:46 +00:00
if (m_inputMethodServerToStart != QStringLiteral("internal")) {
move InputMethod singleton to Application
2022-07-20 10:14:27 +00:00
inputMethod()->setInputMethodCommand(m_inputMethodServerToStart);
inputMethod()->setEnabled(true);
Fix size restore upon keyboard close in XdgSurfaceClient in XdgSurfaceClient setFrameGeometry is async, so we can't rely on it having the final value immediately. make setVirtualKeyboardGeometry a virtual. in the implementation on setVirtualKeyboardGeometry use requestedFrameGeometry() instead of frameGeometry()
2020-09-01 08:58:46 +00:00
}
}
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
// first load options - done internally by a different thread
createOptions();
Refactor session code At the moment, the session code is far from being extensible. If we decide to add support for libseatd, it will be a challenging task with the current design of session management code. The goal of this refactoring is to fix that. Another motivation behind this change is to prepare session related code for upstreaming to kwayland-server where it belongs.
2021-01-30 13:22:07 +00:00
if (!platform()->initialize()) {
std::exit(1);
}
autotests: Fix XwaylandInputTest For some reason, Xwayland doesn't like starting without outputs. If outputs are added later, it sends bogus EnterNotify and LeaveNotify events.
2021-05-13 10:28:20 +00:00
waylandServer()->initPlatform();
Fix NightColorTest Currently, the test crashes because the ColorManager is not created.
2020-12-17 11:03:18 +00:00
createColorManager();
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
// try creating the Wayland Backend
createInput();
Add all three VirtualInputDevices for autotests [3/6] Make autotests create fake input devices This commit adds back all three VirtualInputDevices for simulating keyboard, touch and pointer input events from autotests.
2022-02-26 08:22:31 +00:00
createVirtualInputDevices();
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
Drop Platform::enabledOutputs() At the moment, a platform should provide two output lists - one that lists all available outputs, and the other one that contains only enabled outputs. In general, this amounts to some boilerplate code and forces backends to be implemented in some certain way, which sometimes is inconvenient, e.g. if an output is disabled or enabled, it will be simpler if we only change Output::isEnabled(), otherwise we need to start accounting for corner cases such as the order in which Output::isEnabled() and Platform::enabledOutputs() are changed, etc.
2022-07-21 09:23:43 +00:00
if (!platform()->outputs().isEmpty()) {
Refactor session code At the moment, the session code is far from being extensible. If we decide to add support for libseatd, it will be a challenging task with the current design of session management code. The goal of this refactoring is to fix that. Another motivation behind this change is to prepare session related code for upstreaming to kwayland-server where it belongs.
2021-01-30 13:22:07 +00:00
continueStartupWithScreens();
} else {
connect(platform(), &Platform::screensQueried, this, &WaylandTestApplication::continueStartupWithScreens);
}
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
}
void WaylandTestApplication::continueStartupWithScreens()
{
Rename AbstractBackend to Platform
2016-04-07 07:18:10 +00:00
disconnect(kwinApp()->platform(), &Platform::screensQueried, this, &WaylandTestApplication::continueStartupWithScreens);
Split Compositor class in Wayland and X11 child classes Summary: This patch is a first take at splitting up of the Compositor class into Wayland and X11 child classes. In this first patch we mostly deal with setup and teardown procedures. A future goal is to further differentiate the compositing part itself too. Test Plan: Manually X from VT and Wayland nested. Autotests pass. Reviewers: #kwin Subscribers: sbergeron, anthonyfieroni, zzag, kwin Tags: #kwin Maniphest Tasks: T11071 Differential Revision: https://phabricator.kde.org/D22195
2019-08-07 17:33:20 +00:00
WaylandCompositor::create();
[wayland] Keep application startup flow inside main_wayland Summary: In a recent patch the newly added xwayland class ended up being responsible for continuing the startup, calling back into the main app to spawn the workspace. It moves the flow of startup about so it's not very readable or following class structure. This patch moves the code back into main_wayland and removes the duplication between xwayland and non-xwayland modes. There was also a misnaming of methods. Previously: continueStartupWithScreens was called after platform screens are created continueStartupWithScene was called after the scene was created continueStartupWithXwayland was called before xwayland is created This was confusing, so the names have been shuffled around to follow a consistent pattern of what has been done so far. Test Plan: Started kwin_wayland in normal and xwayland mode Ran unit tests (though some failed due to a local unrelated and as yet unindentified bug) Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19232
2019-02-23 12:17:50 +00:00
connect(Compositor::self(), &Compositor::sceneCreated, this, &WaylandTestApplication::continueStartupWithScene);
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
}
[wayland] Keep application startup flow inside main_wayland Summary: In a recent patch the newly added xwayland class ended up being responsible for continuing the startup, calling back into the main app to spawn the workspace. It moves the flow of startup about so it's not very readable or following class structure. This patch moves the code back into main_wayland and removes the duplication between xwayland and non-xwayland modes. There was also a misnaming of methods. Previously: continueStartupWithScreens was called after platform screens are created continueStartupWithScene was called after the scene was created continueStartupWithXwayland was called before xwayland is created This was confusing, so the names have been shuffled around to follow a consistent pattern of what has been done so far. Test Plan: Started kwin_wayland in normal and xwayland mode Ran unit tests (though some failed due to a local unrelated and as yet unindentified bug) Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19232
2019-02-23 12:17:50 +00:00
void WaylandTestApplication::finalizeStartup()
Ensure Workspace is only started once in Wayland-only mode The connect to Compositor::sceneCreated must be disconnected again, otherwise a restart of the Compositor results in Workspace being created again. Thanks to our autotests for finding this problem!
2017-10-01 07:06:51 +00:00
{
[wayland] Keep application startup flow inside main_wayland Summary: In a recent patch the newly added xwayland class ended up being responsible for continuing the startup, calling back into the main app to spawn the workspace. It moves the flow of startup about so it's not very readable or following class structure. This patch moves the code back into main_wayland and removes the duplication between xwayland and non-xwayland modes. There was also a misnaming of methods. Previously: continueStartupWithScreens was called after platform screens are created continueStartupWithScene was called after the scene was created continueStartupWithXwayland was called before xwayland is created This was confusing, so the names have been shuffled around to follow a consistent pattern of what has been done so far. Test Plan: Started kwin_wayland in normal and xwayland mode Ran unit tests (though some failed due to a local unrelated and as yet unindentified bug) Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19232
2019-02-23 12:17:50 +00:00
if (m_xwayland) {
xwayland: Replace criticalError() signal with a less fatal signal If the Xwayland executable can't be found, the whole session will die because a criticalError() signal will be emitted. This change replaces the criticalError() signal with a less severe signal. If the errorOccurred() signal has been emitted during the startup sequence, kwin won't die and will just continue with spawning the session process.
2020-09-08 08:18:31 +00:00
disconnect(m_xwayland, &Xwl::Xwayland::errorOccurred, this, &WaylandTestApplication::finalizeStartup);
Survive Xwayland crashes If the Xwayland process crashes, it will bring down the entire session together with itself. Obviously, we don't want that. At least, Wayland clients should survive the crash. This change refactors relevant X11 parts to handle Xwayland crashes in a less fatal way. In order to handle Xwayland crashes better, a pair of start() and stop() methods had been introduced in the Xwayland class to allow starting and stopping the Xwayland process at any moment. If we detect that the Xwayland process has crashed, we will immediately stop the Xwayland server, which in its turn will deactivate the socket notifier and destroy all connected X11 clients. Unfortunately, a couple of subtle changes in X11Client::releaseWindow() and Unmanaged::release() had to be made to ensure that we are left with a valid state after the Xwayland server has been stopped.
2020-07-20 08:07:08 +00:00
disconnect(m_xwayland, &Xwl::Xwayland::started, this, &WaylandTestApplication::finalizeStartup);
[wayland] Keep application startup flow inside main_wayland Summary: In a recent patch the newly added xwayland class ended up being responsible for continuing the startup, calling back into the main app to spawn the workspace. It moves the flow of startup about so it's not very readable or following class structure. This patch moves the code back into main_wayland and removes the duplication between xwayland and non-xwayland modes. There was also a misnaming of methods. Previously: continueStartupWithScreens was called after platform screens are created continueStartupWithScene was called after the scene was created continueStartupWithXwayland was called before xwayland is created This was confusing, so the names have been shuffled around to follow a consistent pattern of what has been done so far. Test Plan: Started kwin_wayland in normal and xwayland mode Ran unit tests (though some failed due to a local unrelated and as yet unindentified bug) Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19232
2019-02-23 12:17:50 +00:00
}
Introduce started signal in Application The new signal is emitted when the Application has fully been initialized. It allows us to change the startup sequence, for example create workspace before starting the Xwayland server, without making any adjustments in our test suit.
2020-07-07 09:32:29 +00:00
notifyStarted();
Ensure Workspace is only started once in Wayland-only mode The connect to Compositor::sceneCreated must be disconnected again, otherwise a restart of the Compositor results in Workspace being created again. Thanks to our autotests for finding this problem!
2017-10-01 07:06:51 +00:00
}
[wayland] Keep application startup flow inside main_wayland Summary: In a recent patch the newly added xwayland class ended up being responsible for continuing the startup, calling back into the main app to spawn the workspace. It moves the flow of startup about so it's not very readable or following class structure. This patch moves the code back into main_wayland and removes the duplication between xwayland and non-xwayland modes. There was also a misnaming of methods. Previously: continueStartupWithScreens was called after platform screens are created continueStartupWithScene was called after the scene was created continueStartupWithXwayland was called before xwayland is created This was confusing, so the names have been shuffled around to follow a consistent pattern of what has been done so far. Test Plan: Started kwin_wayland in normal and xwayland mode Ran unit tests (though some failed due to a local unrelated and as yet unindentified bug) Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19232
2019-02-23 12:17:50 +00:00
void WaylandTestApplication::continueStartupWithScene()
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
{
[wayland] Keep application startup flow inside main_wayland Summary: In a recent patch the newly added xwayland class ended up being responsible for continuing the startup, calling back into the main app to spawn the workspace. It moves the flow of startup about so it's not very readable or following class structure. This patch moves the code back into main_wayland and removes the duplication between xwayland and non-xwayland modes. There was also a misnaming of methods. Previously: continueStartupWithScreens was called after platform screens are created continueStartupWithScene was called after the scene was created continueStartupWithXwayland was called before xwayland is created This was confusing, so the names have been shuffled around to follow a consistent pattern of what has been done so far. Test Plan: Started kwin_wayland in normal and xwayland mode Ran unit tests (though some failed due to a local unrelated and as yet unindentified bug) Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19232
2019-02-23 12:17:50 +00:00
disconnect(Compositor::self(), &Compositor::sceneCreated, this, &WaylandTestApplication::continueStartupWithScene);
Start accepting client connections after creating workspace Sub-classes of the AbstractClient class need a valid instance of the Workspace class to function as desired. We should not create xdg-shell clients until the workspace is created.
2020-07-07 09:45:55 +00:00
createWorkspace();
Load plugins after Workspace is created The original intention behind creating plugins before the workspace was to handle the case where kwin_wayland may need to wait until outputs are available. However, since things have changed a lot in that regard, plugins can be loaded after the workspace now. The main benefit behind this is that plugins can be simpler, they won't need to track when the workspace is created. On X11, plugins are already loaded after the workspace is instantiated.
2022-07-21 16:13:07 +00:00
createPlugins();
Start accepting client connections after creating workspace Sub-classes of the AbstractClient class need a valid instance of the Workspace class to function as desired. We should not create xdg-shell clients until the workspace is created.
2020-07-07 09:45:55 +00:00
if (!waylandServer()->start()) {
qFatal("Failed to initialize the Wayland server, exiting now");
}
[wayland] Keep application startup flow inside main_wayland Summary: In a recent patch the newly added xwayland class ended up being responsible for continuing the startup, calling back into the main app to spawn the workspace. It moves the flow of startup about so it's not very readable or following class structure. This patch moves the code back into main_wayland and removes the duplication between xwayland and non-xwayland modes. There was also a misnaming of methods. Previously: continueStartupWithScreens was called after platform screens are created continueStartupWithScene was called after the scene was created continueStartupWithXwayland was called before xwayland is created This was confusing, so the names have been shuffled around to follow a consistent pattern of what has been done so far. Test Plan: Started kwin_wayland in normal and xwayland mode Ran unit tests (though some failed due to a local unrelated and as yet unindentified bug) Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19232
2019-02-23 12:17:50 +00:00
if (operationMode() == OperationModeWaylandOnly) {
finalizeStartup();
return;
}
[autotests] Use Xwayland class in WaylandTestApplication Summary: By using the new Xwayland class we can reduce code duplication. An abstract parent class is introduced, that allows interfacing with the Xwayland class from the test binaries. Test Plan: Autotests still pass. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D15022
2018-08-22 00:20:16 +00:00
m_xwayland = new Xwl::Xwayland(this);
xwayland: Replace criticalError() signal with a less fatal signal If the Xwayland executable can't be found, the whole session will die because a criticalError() signal will be emitted. This change replaces the criticalError() signal with a less severe signal. If the errorOccurred() signal has been emitted during the startup sequence, kwin won't die and will just continue with spawning the session process.
2020-09-08 08:18:31 +00:00
connect(m_xwayland, &Xwl::Xwayland::errorOccurred, this, &WaylandTestApplication::finalizeStartup);
Survive Xwayland crashes If the Xwayland process crashes, it will bring down the entire session together with itself. Obviously, we don't want that. At least, Wayland clients should survive the crash. This change refactors relevant X11 parts to handle Xwayland crashes in a less fatal way. In order to handle Xwayland crashes better, a pair of start() and stop() methods had been introduced in the Xwayland class to allow starting and stopping the Xwayland process at any moment. If we detect that the Xwayland process has crashed, we will immediately stop the Xwayland server, which in its turn will deactivate the socket notifier and destroy all connected X11 clients. Unfortunately, a couple of subtle changes in X11Client::releaseWindow() and Unmanaged::release() had to be made to ensure that we are left with a valid state after the Xwayland server has been stopped.
2020-07-20 08:07:08 +00:00
connect(m_xwayland, &Xwl::Xwayland::started, this, &WaylandTestApplication::finalizeStartup);
m_xwayland->start();
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
}
Add all three VirtualInputDevices for autotests [3/6] Make autotests create fake input devices This commit adds back all three VirtualInputDevices for simulating keyboard, touch and pointer input events from autotests.
2022-02-26 08:22:31 +00:00
Test::VirtualInputDevice *WaylandTestApplication::virtualPointer() const
{
return m_virtualPointer.get();
}
Test::VirtualInputDevice *WaylandTestApplication::virtualKeyboard() const
{
return m_virtualKeyboard.get();
}
Test::VirtualInputDevice *WaylandTestApplication::virtualTouch() const
{
return m_virtualTouch.get();
}
[autotest] Welcome to integration testing KWin This is the beginning of a new testing era for KWin: finally we are able to test against a running KWin. This works by making use of the new virtual framebuffer backend for Wayland. It starts a specific Application subclass which is mostly a fork of ApplicationWayland. The individual tests are able to influence the socket name and the size of the virtual screen. This is supposed to be done in initTestCase. To know when KWin is fully started one can use the workspaceCreated signal of KWin::Application. KWin is not started in another process, but the kwin library is used, so the test has pretty much full introspection to everything going on inside KWin. It can access the Workspace, WaylandServer, fake input events through InputRedirection and so on. Once the test KWin is running it's possible to connect to it using KWayland::Client library. This allows to introspect the Workspace to see whether all worked as expected (e.g. correct stacking order, active window and so on). This first autotest is mostly meant to illustrate how to setup a test and how one can use KWayland::Client to interact with the mock KWin. For more tests it is suggested to move the connections to the Wayland server in the init() and cleanup() methods. The change also affects the qpa plugin: the specific check to only run in binaries called kwin_wayland doesn't hold any more. This can now be overwritten by an env variable. Please note that this first test will probably fail in the CI system as it might not have XWayland which is needed by KWin.
2015-10-02 13:04:57 +00:00
}
Reference in a new issue Copy permalink