yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/src/main_wayland.cpp

630 lines
24 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.
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2014 Martin Gräßlin <mgraesslin@kde.org>
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
#include "main_wayland.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 <config-kwin.h>
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/drm/drm_backend.h"
#include "backends/virtual/virtual_backend.h"
#include "backends/wayland/wayland_backend.h"
backends/x11/windowed: rename files to be more consistent
2022-07-22 17:25:05 +00:00
#include "backends/x11/windowed/x11_windowed_backend.h"
Only start Xwayland server if Compositor created a Scene So far if the Scene creation failed kwin_wayland went into a shutdown, but didn't succeed because the thread to start Xwayland was already running: it froze. This change introduces a new signal in Compositor: sceneCreated. The startup of Xwayland is bound to this signal. If it gets fired KWin can startup Xwayland. If it does not get fired, KWin terminates correctly.
2016-04-14 06:51:16 +00:00
#include "composite.h"
core: Rename Platform to OutputBackend
2022-11-05 10:43:41 +00:00
#include "core/outputbackend.h"
Move multi-purpose code in its own directory Things such as Output, InputDevice and so on are made to be multi-purpose. In order to make this separation more clear, this change moves that code in the core directory. Some things still link to the abstraction level above (kwin), they can be tackled in future refactors. Ideally code in core/ should depend either on other code in core/ or system libs.
2022-08-29 07:55:49 +00:00
#include "core/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 "effects.h"
virtualkeyboard: rename class to InputMethod VirtualKeyboard class does not implement the relevant VirtualKeyboard protocol but rather implements the InputMethod protcol and can in theory be used by other input method like e.g. ibus. Make class name consistent with what it does to avoid confusion in future. For now only rename of main class is done and dbus service is kept as-is to provide retro-compatibility, when input method protocol is implemented fully, we can think of what to do wrt the dbus interface later when we fully implement zwp_input_method_unstable_v1 protocol.
2020-09-29 14:46:32 +00:00
#include "inputmethod.h"
A basic TabletModeManager Summary: depends from D9521 listens to switch events and updates the tablet mode status which is exposed to dbus in the org.kde.KWin.TabletModeManager interface Test Plan: as hardware support is limited, testing of clients so far is done by the setter in the dbus property, which should be removed from the final version. It has been tested to successfully work on a Thinkpad. Reviewers: #plasma, #kwin, graesslin Reviewed By: #plasma, #kwin, graesslin Subscribers: graesslin, davidedmundson, plasma-devel, kwin, #kwin Tags: #plasma Differential Revision: https://phabricator.kde.org/D9764
2018-01-11 12:09:43 +00:00
#include "tabletmodemanager.h"
wayland: Make setting realtime scheduler more fine grained With this only the main and the libinput threads will use realtime scheduling, so it will be harder to leak realtime scheduling to somebody else. The only caveat is that kwin would need to keep CAP_SYS_NICE around, however on the other hand, it's needed to ensure that kwin_wayland is able to get high priority EGL contexts with some drivers, e.g. intel.
2022-05-16 07:31:30 +00:00
#include "utils/realtime.h"
Integrate kwaylandserver This makes KWin switch to in-tree copy of KWaylandServer codebase. KWaylandServer namespace has been left as is. It will be addressed later by renaming classes in order to fit in the KWin namespace.
2022-04-22 09:27:33 +00:00
#include "wayland/display.h"
#include "wayland/seat_interface.h"
Let the fun begin: start a WaylandServer in kwin_wayland The WaylandServer is at the moment only used to support starting an Xwayland. It does not support Wayland clients yet, so don't get excited. For Xwayland it's using the trick of creating the Display before the QApplication is created with manual event dispatching.
2015-02-09 12:28:37 +00:00
#include "wayland_server.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 "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"
#include "xwayland/xwaylandlauncher.h"
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
// KDE
[wayland] Pass command line arguments to launched processes Summary: Since QProcess::setProgram() doesn't split the command, we need to do it ourselves. Test Plan: `dbus-run-session kwin_wayland "kate foo.txt"` works again. Reviewers: #kwin, cblack, davidedmundson, apol Reviewed By: #kwin, cblack, davidedmundson, apol Subscribers: apol, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D29253
2020-04-28 12:45:34 +00:00
#include <KCrash>
Introduce a setting to specify an input method At the moment we are getting the input method from the command line which is not very handy (but very secure). This patch changes it so it can be specified from a configuration setting. CCBUG: 427972
2020-12-23 00:41:47 +00:00
#include <KDesktopFile>
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
#include <KLocalizedString>
[wayland] Pass command line arguments to launched processes Summary: Since QProcess::setProgram() doesn't split the command, we need to do it ourselves. Test Plan: `dbus-run-session kwin_wayland "kate foo.txt"` works again. Reviewers: #kwin, cblack, davidedmundson, apol Reviewed By: #kwin, cblack, davidedmundson, apol Subscribers: apol, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D29253
2020-04-28 12:45:34 +00:00
#include <KShell>
Fix handling of different signals (SIGTERM et al) by using KSignalHandler When debugging something I realised that SIGTERM was always making KWin crash like I'd never seen it crash. It turns out we are calling QApplication::exit() on the signal handler which is highly forbidden as the handler preempts the process altogether. Use KSignalHandler instead which takes this issue into account.
2022-09-15 15:18:44 +00:00
#include <KSignalHandler>
Load QtQuick settings Summary: Loads settings on whether QtQuick uses GL or software rendering Aurorae needed a fix. The rest "just works" with up-to-date plasma framework. Test Plan: Alt tabbed Showed an OSD Grepped kwin's QML for any custom shaders. (which is the only part that doesn't work here) Reviewers: #plasma, graesslin Reviewed By: #plasma, graesslin Subscribers: graesslin, plasma-devel, kwin, #kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D8040
2017-11-01 15:45:05 +00:00
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
// Qt
#include <QCommandLineParser>
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 <QDBusInterface>
#include <QDebug>
[wayland] Disallow ptrace on kwin_wayland process In order to increase the security we disable ptrace on kwin_wayland. This makes it impossible for a another process running as the same user to attach to kwin_wayland to install a key logger. It doesn't protect against higher privileged users, but that's no problem: they can just read the input device file and don't need to attach to KWin to become a key logger. This change is highly inspired by a similar change to kscreenlocker. A difference is that KWin checks whether we are running under a debugger. In such a case we still want to allow ptrace.
2015-12-08 10:42:48 +00:00
#include <QFileInfo>
[wayland] Add positional arguments to be programs to starts This allows to start applications once kwin_wayland is started. E.g. kwin_wayland --libinput --xwayland --framebuffer /usr/bin/startkde Thus it would start startkde once both Wayland Server and Xwayland are up and running and ready for connection. This resolves the problem that prior to startup it is not known which will be the X11 display variable. By passing the environment to the process by KWin this problem is resolved.
2015-04-21 09:21:28 +00:00
#include <QProcess>
[kwin_waylnad] Fix support for QtWayland's client buffer integration QtWayland performs an eglInitialize in the main thread when for the first time an OpenGL context/window is needed. In KWin's startup this happens during initializing Scripting which creates a QDesktopWidget and triggers the creation of a QWindow with a RasterGLSurface. Calling eglInitialize in the main thread blocks as it calls wl_roundtrip. We cannot just disable OpenGL as that would mean that we cannot use QtQuick. The workaround in this change is to create a QWindow with a RasterGLSurface in a thread and call create on it. This ensures that OpenGL gets initialized in the thread and doesn't block.
2015-02-25 10:42:56 +00:00
#include <QWindow>
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 <qplatformdefs.h>
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
Use real-time scheduling policy for kwin_wayland Summary: The base idea behind this change is to keep the system responsive no matter what other processes do. All input and rendering needs to go through the windowing system, so keeping it responsive is important. Currently KWin competes with all other processes for resources and this can render the system unusable. Consider some processes running amok. In this case the user might not be able to easily close the applications as KWin does not get the cpu time to perform the input tasks requested by the user. Or in the case of playing a demanding game it is important that KWin gets scheduled to forward the pointer input events. The user doesn't want that the game (or another process) wins against the windowing sytem. The disadvantage is that KWin always wins against other processes with real time scheduling. This could result in KWin running amok stalling the system. On the other hand this is no change to the current situation as if KWin runs amok the sytem is unusable. The change uses libcap to set CAP_SYS_NICE on kwin_wayland executable. KWin_wayland on start sets the scheduling policy to SCHED_RR with the lowest possible priority. Thus any other SCHED_RR process will win against KWin. So real time processes are not affected by this change! After adjusting the scheduling (which requires CAP_SYS_NICE) KWin drops this capability again. Test Plan: Verified that KWin adjusts the scheduler, that it is not passed to child processes, that the capability gets dropped and not passed to child processes. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7757
2017-09-10 10:05:29 +00:00
#include <sched.h>
wayland: Bump RLIMIT_NOFILE limit As a wayland compositor kwin can hold many open file descriptors and therefore it's easier for it to hit the soft file descriptor limit. This change makes kwin_wayland bump the soft file descriptor limit to the hard limit. With systemd, it's usually 500K. In order to prevent causing mess in child processes, pthread_atfork() is used to register a handler which will be invoked in the child process after fork() in order to restore RLIMIT_NOFILE to its original value.
2022-05-15 13:22:35 +00:00
#include <sys/resource.h>
Use real-time scheduling policy for kwin_wayland Summary: The base idea behind this change is to keep the system responsive no matter what other processes do. All input and rendering needs to go through the windowing system, so keeping it responsive is important. Currently KWin competes with all other processes for resources and this can render the system unusable. Consider some processes running amok. In this case the user might not be able to easily close the applications as KWin does not get the cpu time to perform the input tasks requested by the user. Or in the case of playing a demanding game it is important that KWin gets scheduled to forward the pointer input events. The user doesn't want that the game (or another process) wins against the windowing sytem. The disadvantage is that KWin always wins against other processes with real time scheduling. This could result in KWin running amok stalling the system. On the other hand this is no change to the current situation as if KWin runs amok the sytem is unusable. The change uses libcap to set CAP_SYS_NICE on kwin_wayland executable. KWin_wayland on start sets the scheduling policy to SCHED_RR with the lowest possible priority. Thus any other SCHED_RR process will win against KWin. So real time processes are not affected by this change! After adjusting the scheduling (which requires CAP_SYS_NICE) KWin drops this capability again. Test Plan: Verified that KWin adjusts the scheduler, that it is not passed to child processes, that the capability gets dropped and not passed to child processes. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7757
2017-09-10 10:05:29 +00:00
[wayland] Add a --list-backends command line arg for listing available backends Distributions do package each backend plugin in a dedicated package, which means just because KWin got compiled with a specific backend, doesn't mean it is also available at runtime. In order to better support this reality this change introduces a list-backends command line option. Each of the plugins got the json metadata extended by the KPlugin syntax, so that we have a name and description to print. As we already locate all plugins anyway, the additional findPlugins for the selected backend is changed to search the list of all plugin meta data.
2015-10-02 07:31:47 +00:00
#include <iomanip>
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 <iostream>
[kwin_wayland] Add config option to start an X Server KWin_Wayland still needs an X-Server. To simplify the development setup the required X-Server can be started through a command line argument together with KWin. Unfortunately the command line arguments processing needs to be done by hand as QCommandLineParser only allows processing after QApplication is created which requires the started X Server. The nested X-Server is started by forking the application and using execlp to load the binary. In addition a pipe is created to allow the X-Server to write the display number to once it's ready to connect and by that KWin is ready to create the QApplication.
2014-08-12 13:27:35 +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)
Use #cmakedefine01 for the remaining config macros Using 0/1 instead of undefined/defined to 1 allows the compiler to flag a missing include of the config header.
2022-02-28 19:12:30 +00:00
#if PipeWire_FOUND
Introduce infrastructure for compositor extensions The scripting api is not suitable for implementing all features that should not be implemented in libkwin. For example, the krunner integration or screencasting are the things that don't belong to be compiled right into kwin and yet we don't have any other choice. This change introduces a quick and dirty plugin infrastructure that can be used to implement things such as colord integration, krunner integration, etc.
2020-11-07 19:34:55 +00:00
Q_IMPORT_PLUGIN(ScreencastManagerFactory)
#endif
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
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
namespace KWin
{
wayland: Bump RLIMIT_NOFILE limit As a wayland compositor kwin can hold many open file descriptors and therefore it's easier for it to hit the soft file descriptor limit. This change makes kwin_wayland bump the soft file descriptor limit to the hard limit. With systemd, it's usually 500K. In order to prevent causing mess in child processes, pthread_atfork() is used to register a handler which will be invoked in the child process after fork() in order to restore RLIMIT_NOFILE to its original value.
2022-05-15 13:22:35 +00:00
static rlimit originalNofileLimit = {
.rlim_cur = 0,
.rlim_max = 0,
};
static bool bumpNofileLimit()
{
if (getrlimit(RLIMIT_NOFILE, &originalNofileLimit) == -1) {
std::cerr << "Failed to bump RLIMIT_NOFILE limit, getrlimit() failed: " << strerror(errno) << std::endl;
return false;
}
rlimit limit = originalNofileLimit;
limit.rlim_cur = limit.rlim_max;
if (setrlimit(RLIMIT_NOFILE, &limit) == -1) {
std::cerr << "Failed to bump RLIMIT_NOFILE limit, setrlimit() failed: " << strerror(errno) << std::endl;
return false;
}
return true;
}
static void restoreNofileLimit()
{
if (setrlimit(RLIMIT_NOFILE, &originalNofileLimit) == -1) {
std::cerr << "Failed to restore RLIMIT_NOFILE limit, legacy apps might be broken" << std::endl;
}
}
Explicitly link and disable kcrash on kwin_wayland Summary: Kwin tried to not use kcrash by not linking against it. KIO now links against KCrash as we link against KIO we indirectly link against KCrash and thus now link and launch kcrash on wayland. This breaks coredump. Arguably it should be fixed in KIO, but it's non-trivial. The advantage of this approach is it allows us to enable drkonqi for nested mode in the future, or make a non-gui drkonqi that just saves logs. Test Plan: Compiles Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: zzag, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16834
2018-11-12 09:58:36 +00:00
void disableDrKonqi()
{
KCrash::setDrKonqiEnabled(false);
}
// run immediately, before Q_CORE_STARTUP functions
// that would enable drkonqi
Q_CONSTRUCTOR_FUNCTION(disableDrKonqi)
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
//************************************
// ApplicationWayland
//************************************
ApplicationWayland::ApplicationWayland(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(OperationModeWaylandOnly, argc, argv)
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
{
}
ApplicationWayland::~ApplicationWayland()
{
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();
Add a check for waylandServer in the dtor before using it Make sure the waylandServer ptr exists before referencing it in the dtor. REVIEW: 126190
2015-11-30 14:57:22 +00:00
if (!waylandServer()) {
return;
}
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
destroyPlugins();
[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
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
}
core: port a few things away from manual memory management
2022-07-05 11:43:25 +00:00
m_xwayland.reset();
Create color manager after workspace
2022-07-23 12:39:17 +00:00
destroyColorManager();
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();
wayland: Destroy InputRedirection explicitly CCBUG: 442104
2021-09-27 10:02:24 +00:00
destroyInput();
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
}
void ApplicationWayland::performStartup()
{
Drop OperationModeX11AndWayland and introduce OperationModeWaylandOnly instead The operation mode X11 and Wayland is no longer supported and probably hasn't been supported for the last few years. But now there is the possibility to run Wayland only, so introduce this as a dedicated new OperationMode.
2017-09-30 13:09:06 +00:00
if (m_startXWayland) {
setOperationMode(OperationModeXwayland);
Support an alternative harcoded scale for X Anything in xcb_ structs are always in X local, all member variables aside from buffers are in kwin local space. This patch ignores a few paths that are not relevant on wayland.
2022-02-02 03:35:13 +00:00
setXwaylandScale(config()->group("Xwayland").readEntry("Scale", 1.0));
Drop OperationModeX11AndWayland and introduce OperationModeWaylandOnly instead The operation mode X11 and Wayland is no longer supported and probably hasn't been supported for the last few years. But now there is the possibility to run Wayland only, so introduce this as a dedicated new OperationMode.
2017-09-30 13:09:06 +00:00
}
[wayland] Start Compositor and Scene before Workspace For Xwayland we need to have the Scene (and EglDisplay) created prior to starting Xwayland and having X11. This requires creating the Compositor before creating Workspace and starting Xwayland. To support this the startup of Compositor is split into two parts: prior and after Workspace creation. The change might also be interesting for the kwin_x11 case as it could result in the compositor being up in a quicker way.
2015-02-23 14:57:00 +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
core: Rename Platform to OutputBackend
2022-11-05 10:43:41 +00:00
if (!outputBackend()->initialize()) {
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
std::exit(1);
}
[kwin_wayland] Create screens prior to Xwayland Gives us the correct outputs in Xwayland direct from start.
2015-02-20 13:57:06 +00:00
createInput();
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
createInputMethod();
tabletmodemanager: move global to Application
2022-08-03 09:27:35 +00:00
createTabletModeManager();
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
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();
Rearrange wayland startup sequence The backend can now optionally wait for the scene to be created before it updates its outputs, which is necessary for better atomic tests in the DRM backend.
2021-05-18 23:05:41 +00:00
core: Rename Platform to OutputBackend
2022-11-05 10:43:41 +00:00
connect(Compositor::self(), &Compositor::sceneCreated, outputBackend(), &OutputBackend::sceneInitialized);
[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, &ApplicationWayland::continueStartupWithScene);
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
}
Rearrange wayland startup sequence The backend can now optionally wait for the scene to be created before it updates its outputs, which is necessary for better atomic tests in the DRM backend.
2021-05-18 23:05:41 +00:00
void ApplicationWayland::continueStartupWithScene()
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
{
Rearrange wayland startup sequence The backend can now optionally wait for the scene to be created before it updates its outputs, which is necessary for better atomic tests in the DRM backend.
2021-05-18 23:05:41 +00:00
disconnect(Compositor::self(), &Compositor::sceneCreated, this, &ApplicationWayland::continueStartupWithScene);
[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
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
// Note that we start accepting client connections after creating the Workspace.
createWorkspace();
Create color manager after workspace
2022-07-23 12:39:17 +00:00
createColorManager();
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 initialze 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;
}
[xwl] Move Xwayland parts into separate class Summary: The Xwayland code path is moved from ApplicationWayland to a dedicated class Xwayland in a new top-level directory xwl. This is a direct preparation step for generic support of Xwayland Selections. On a longer timescale this should also allow us to further separate Wayland native functionality from Xwayland to allow us at one point to build KWin's Wayland binary optionally without X dependencies. Another long term goal, that becomes possible through this separation is to recover from Xwayland crashes. Test Plan: Manually and auto tests Reviewers: #kwin, davidedmundson Subscribers: davidedmundson, zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D15020
2019-02-19 08:50:20 +00:00
core: port a few things away from manual memory management
2022-07-05 11:43:25 +00:00
m_xwayland = std::make_unique<Xwl::Xwayland>(this);
XWayland:split connection and process spawning These are two conceptually different tasks that were intertwined. On it's own it doesn't accomplish anything but is an important refactor for longer term goals, namely: - moving xwayland into kwin_wayland_wrapper with our wayland restart handling support - having multiple X connections Behaviour should be the same.
2022-03-12 14:09:57 +00:00
m_xwayland->xwaylandLauncher()->setListenFDs(m_xwaylandListenFds);
m_xwayland->xwaylandLauncher()->setDisplayName(m_xwaylandDisplay);
m_xwayland->xwaylandLauncher()->setXauthority(m_xwaylandXauthority);
core: port a few things away from manual memory management
2022-07-05 11:43:25 +00:00
connect(m_xwayland.get(), &Xwl::Xwayland::errorOccurred, this, &ApplicationWayland::finalizeStartup);
connect(m_xwayland.get(), &Xwl::Xwayland::started, this, &ApplicationWayland::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
m_xwayland->start();
Support starting kwin_wayland without XWayland support Summary: Just continues with the steps without starting XWayland. This does not yet fully support kwin_wayland without X11, it currently still crashes on teardown. Test Plan: kwin_wayland --socket=wayland-1 kwrite (note the missing --xwayland) Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7924
2017-09-21 16:27:47 +00:00
}
Rearrange wayland startup sequence The backend can now optionally wait for the scene to be created before it updates its outputs, which is necessary for better atomic tests in the DRM backend.
2021-05-18 23:05:41 +00:00
void ApplicationWayland::finalizeStartup()
{
if (m_xwayland) {
core: port a few things away from manual memory management
2022-07-05 11:43:25 +00:00
disconnect(m_xwayland.get(), &Xwl::Xwayland::errorOccurred, this, &ApplicationWayland::finalizeStartup);
disconnect(m_xwayland.get(), &Xwl::Xwayland::started, this, &ApplicationWayland::finalizeStartup);
Rearrange wayland startup sequence The backend can now optionally wait for the scene to be created before it updates its outputs, which is necessary for better atomic tests in the DRM backend.
2021-05-18 23:05:41 +00:00
}
startSession();
notifyStarted();
}
Introduce a setting to specify an input method At the moment we are getting the input method from the command line which is not very handy (but very secure). This patch changes it so it can be specified from a configuration setting. CCBUG: 427972
2020-12-23 00:41:47 +00:00
void ApplicationWayland::refreshSettings(const KConfigGroup &group, const QByteArrayList &names)
{
xwayland: Listen to changes in the Xwayland.Scale setting
2022-06-08 13:45:28 +00:00
if (group.name() == "Wayland" && names.contains("InputMethod")) {
KDesktopFile file(group.readPathEntry("InputMethod", QString()));
move InputMethod singleton to Application
2022-07-20 10:14:27 +00:00
kwinApp()->inputMethod()->setInputMethodCommand(file.desktopGroup().readEntry("Exec", QString()));
Introduce a setting to specify an input method At the moment we are getting the input method from the command line which is not very handy (but very secure). This patch changes it so it can be specified from a configuration setting. CCBUG: 427972
2020-12-23 00:41:47 +00:00
}
xwayland: Listen to changes in the Xwayland.Scale setting
2022-06-08 13:45:28 +00:00
if (m_startXWayland && group.name() == "Xwayland" && names.contains("Scale")) {
setXwaylandScale(group.readEntry("Scale", 1.0));
}
Introduce a setting to specify an input method At the moment we are getting the input method from the command line which is not very handy (but very secure). This patch changes it so it can be specified from a configuration setting. CCBUG: 427972
2020-12-23 00:41:47 +00:00
}
Support starting kwin_wayland without XWayland support Summary: Just continues with the steps without starting XWayland. This does not yet fully support kwin_wayland without X11, it currently still crashes on teardown. Test Plan: kwin_wayland --socket=wayland-1 kwrite (note the missing --xwayland) Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7924
2017-09-21 16:27:47 +00:00
void ApplicationWayland::startSession()
{
WaylandServer: Add a setting to disable PrimarySelection CCBUG: 441668
2022-05-28 14:38:53 +00:00
KSharedConfig::Ptr kwinSettings = kwinApp()->config();
m_settingsWatcher = KConfigWatcher::create(kwinSettings);
connect(m_settingsWatcher.data(), &KConfigWatcher::configChanged, this, &ApplicationWayland::refreshSettings);
[wayland] Add a command-line option to start an input method server Input-method servers, like maliit, need to be known to KWin since KWin needs to know about virtual keyboards. Virtual keyboards should be shown as OSD layers, and they are one of the types of windows that actually should be showable when the lock screen is active. kwin_wayland --inputmethod /path/to/your/input-server tries to start the input server. The input-server's window never gets keyboard focus and is shown on top of all windows except for KWin's internal clients.
2015-06-13 02:06:12 +00:00
if (!m_inputMethodServerToStart.isEmpty()) {
move InputMethod singleton to Application
2022-07-20 10:14:27 +00:00
kwinApp()->inputMethod()->setInputMethodCommand(m_inputMethodServerToStart);
Introduce a setting to specify an input method At the moment we are getting the input method from the command line which is not very handy (but very secure). This patch changes it so it can be specified from a configuration setting. CCBUG: 427972
2020-12-23 00:41:47 +00:00
} else {
inputmethod: fix how we update to input method changes Properly notify about changes from the kcm and properly integrate them. So far it only worked between having and not having a keyboard.
2021-04-27 19:20:20 +00:00
refreshSettings(kwinSettings->group("Wayland"), {"InputMethod"});
[wayland] Add a command-line option to start an input method server Input-method servers, like maliit, need to be known to KWin since KWin needs to know about virtual keyboards. Virtual keyboards should be shown as OSD layers, and they are one of the types of windows that actually should be showable when the lock screen is active. kwin_wayland --inputmethod /path/to/your/input-server tries to start the input server. The input-server's window never gets keyboard focus and is shown on top of all windows except for KWin's internal clients.
2015-06-13 02:06:12 +00:00
}
[wayland] Introduce an additional --exit-with-session command line arg This is similar to the applications to start. That is the value of the command line argument is interpreted as a command to start. The difference is that when this application exits, KWin will also quit. The argument is so to say interpreted as a session. Reviewed-By: Bhushan Shah
2015-11-19 08:16:23 +00:00
// start session
if (!m_sessionArgument.isEmpty()) {
[wayland] Pass command line arguments to launched processes Summary: Since QProcess::setProgram() doesn't split the command, we need to do it ourselves. Test Plan: `dbus-run-session kwin_wayland "kate foo.txt"` works again. Reviewers: #kwin, cblack, davidedmundson, apol Reviewed By: #kwin, cblack, davidedmundson, apol Subscribers: apol, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D29253
2020-04-28 12:45:34 +00:00
QStringList arguments = KShell::splitArgs(m_sessionArgument);
if (!arguments.isEmpty()) {
QString program = arguments.takeFirst();
Drop Process helper Direct session is long time gone and SIGUSR1 and SIGUSR2 are not used anywhere so drop the Process helper.
2022-01-10 20:30:37 +00:00
QProcess *p = new QProcess(this);
[wayland] Pass command line arguments to launched processes Summary: Since QProcess::setProgram() doesn't split the command, we need to do it ourselves. Test Plan: `dbus-run-session kwin_wayland "kate foo.txt"` works again. Reviewers: #kwin, cblack, davidedmundson, apol Reviewed By: #kwin, cblack, davidedmundson, apol Subscribers: apol, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D29253
2020-04-28 12:45:34 +00:00
p->setProcessChannelMode(QProcess::ForwardedErrorChannel);
p->setProcessEnvironment(processStartupEnvironment());
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
connect(p, qOverload<int, QProcess::ExitStatus>(&QProcess::finished), this, [p](int code, QProcess::ExitStatus status) {
[wayland] Pass command line arguments to launched processes Summary: Since QProcess::setProgram() doesn't split the command, we need to do it ourselves. Test Plan: `dbus-run-session kwin_wayland "kate foo.txt"` works again. Reviewers: #kwin, cblack, davidedmundson, apol Reviewed By: #kwin, cblack, davidedmundson, apol Subscribers: apol, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D29253
2020-04-28 12:45:34 +00:00
p->deleteLater();
if (status == QProcess::CrashExit) {
qWarning() << "Session process has crashed";
QCoreApplication::exit(-1);
return;
}
Forward and log exit code of the nested process Summary: Otherwise it's hard to tell if it failed. Test Plan: Found out that my session was crashing. Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D21465
2019-05-28 16:42:55 +00:00
[wayland] Pass command line arguments to launched processes Summary: Since QProcess::setProgram() doesn't split the command, we need to do it ourselves. Test Plan: `dbus-run-session kwin_wayland "kate foo.txt"` works again. Reviewers: #kwin, cblack, davidedmundson, apol Reviewed By: #kwin, cblack, davidedmundson, apol Subscribers: apol, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D29253
2020-04-28 12:45:34 +00:00
if (code) {
qWarning() << "Session process exited with code" << code;
}
Forward and log exit code of the nested process Summary: Otherwise it's hard to tell if it failed. Test Plan: Found out that my session was crashing. Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D21465
2019-05-28 16:42:55 +00:00
[wayland] Pass command line arguments to launched processes Summary: Since QProcess::setProgram() doesn't split the command, we need to do it ourselves. Test Plan: `dbus-run-session kwin_wayland "kate foo.txt"` works again. Reviewers: #kwin, cblack, davidedmundson, apol Reviewed By: #kwin, cblack, davidedmundson, apol Subscribers: apol, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D29253
2020-04-28 12:45:34 +00:00
QCoreApplication::exit(code);
});
p->setProgram(program);
p->setArguments(arguments);
p->start();
} else {
qWarning("Failed to launch the session process: %s is an invalid command",
qPrintable(m_sessionArgument));
}
[wayland] Introduce an additional --exit-with-session command line arg This is similar to the applications to start. That is the value of the command line argument is interpreted as a command to start. The difference is that when this application exits, KWin will also quit. The argument is so to say interpreted as a session. Reviewed-By: Bhushan Shah
2015-11-19 08:16:23 +00:00
}
[wayland] Add positional arguments to be programs to starts This allows to start applications once kwin_wayland is started. E.g. kwin_wayland --libinput --xwayland --framebuffer /usr/bin/startkde Thus it would start startkde once both Wayland Server and Xwayland are up and running and ready for connection. This resolves the problem that prior to startup it is not known which will be the X11 display variable. By passing the environment to the process by KWin this problem is resolved.
2015-04-21 09:21:28 +00:00
// start the applications passed to us as command line arguments
if (!m_applicationsToStart.isEmpty()) {
qAsConst -> std::as_const We started using std::as_const() in some parts of kwin, so let's use it everywhere for the code consistency sake.
2022-10-31 19:02:23 +00:00
for (const QString &application : std::as_const(m_applicationsToStart)) {
[wayland] Pass command line arguments to launched processes Summary: Since QProcess::setProgram() doesn't split the command, we need to do it ourselves. Test Plan: `dbus-run-session kwin_wayland "kate foo.txt"` works again. Reviewers: #kwin, cblack, davidedmundson, apol Reviewed By: #kwin, cblack, davidedmundson, apol Subscribers: apol, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D29253
2020-04-28 12:45:34 +00:00
QStringList arguments = KShell::splitArgs(application);
if (arguments.isEmpty()) {
qWarning("Failed to launch application: %s is an invalid command",
qPrintable(application));
continue;
}
QString program = arguments.takeFirst();
[wayland] Add positional arguments to be programs to starts This allows to start applications once kwin_wayland is started. E.g. kwin_wayland --libinput --xwayland --framebuffer /usr/bin/startkde Thus it would start startkde once both Wayland Server and Xwayland are up and running and ready for connection. This resolves the problem that prior to startup it is not known which will be the X11 display variable. By passing the environment to the process by KWin this problem is resolved.
2015-04-21 09:21:28 +00:00
// note: this will kill the started process when we exit
// this is going to happen anyway as we are the wayland and X server the app connects to
Drop Process helper Direct session is long time gone and SIGUSR1 and SIGUSR2 are not used anywhere so drop the Process helper.
2022-01-10 20:30:37 +00:00
QProcess *p = new QProcess(this);
[wayland] Forward error channel of launched processes This ensures that the redirection to xwayland-errors works properly for a complete session.
2015-12-15 09:08:36 +00:00
p->setProcessChannelMode(QProcess::ForwardedErrorChannel);
[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
p->setProcessEnvironment(processStartupEnvironment());
[wayland] Pass command line arguments to launched processes Summary: Since QProcess::setProgram() doesn't split the command, we need to do it ourselves. Test Plan: `dbus-run-session kwin_wayland "kate foo.txt"` works again. Reviewers: #kwin, cblack, davidedmundson, apol Reviewed By: #kwin, cblack, davidedmundson, apol Subscribers: apol, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D29253
2020-04-28 12:45:34 +00:00
p->setProgram(program);
p->setArguments(arguments);
Fix compiler warnings Summary: No need to keep them around for no reason. Test Plan: Tested the plugins I thought could be affected. Have been using it for a couple of days without problems Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28062
2020-03-15 19:59:29 +00:00
p->startDetached();
p->deleteLater();
[wayland] Add positional arguments to be programs to starts This allows to start applications once kwin_wayland is started. E.g. kwin_wayland --libinput --xwayland --framebuffer /usr/bin/startkde Thus it would start startkde once both Wayland Server and Xwayland are up and running and ready for connection. This resolves the problem that prior to startup it is not known which will be the X11 display variable. By passing the environment to the process by KWin this problem is resolved.
2015-04-21 09:21:28 +00:00
}
}
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
}
xwaylandinterface: move global to Application
2022-08-03 10:31:27 +00:00
XwaylandInterface *ApplicationWayland::xwayland() const
{
return m_xwayland.get();
}
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
} // namespace
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
int main(int argc, char *argv[])
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
{
KWin::Application::setupMalloc();
KWin::Application::setupLocalizedString();
Use real-time scheduling policy for kwin_wayland Summary: The base idea behind this change is to keep the system responsive no matter what other processes do. All input and rendering needs to go through the windowing system, so keeping it responsive is important. Currently KWin competes with all other processes for resources and this can render the system unusable. Consider some processes running amok. In this case the user might not be able to easily close the applications as KWin does not get the cpu time to perform the input tasks requested by the user. Or in the case of playing a demanding game it is important that KWin gets scheduled to forward the pointer input events. The user doesn't want that the game (or another process) wins against the windowing sytem. The disadvantage is that KWin always wins against other processes with real time scheduling. This could result in KWin running amok stalling the system. On the other hand this is no change to the current situation as if KWin runs amok the sytem is unusable. The change uses libcap to set CAP_SYS_NICE on kwin_wayland executable. KWin_wayland on start sets the scheduling policy to SCHED_RR with the lowest possible priority. Thus any other SCHED_RR process will win against KWin. So real time processes are not affected by this change! After adjusting the scheduling (which requires CAP_SYS_NICE) KWin drops this capability again. Test Plan: Verified that KWin adjusts the scheduler, that it is not passed to child processes, that the capability gets dropped and not passed to child processes. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7757
2017-09-10 10:05:29 +00:00
KWin::gainRealTime();
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
[effects] Add a screenshot dbus method which takes a file descriptor Summary: The idea behind this mode is to support applications like spectacle (see T4458). The calling application passes a file descriptor (created through e.g. a pipe) and the screenshot effect writes the captured image into that fd. The advantage over the existing variant which writes to a file in the /tmp directory is that this is peer-to-peer between the requesting application and KWin. No other application can get to that image. The change also includes setting SIGPIPE to ignore. It showed that when the reading side already cancelled the read prior to KWin writing out the image we get a SIGPIPE which results in application termination, which is not what we want in case of a Wayland compositor. The sigpipe can be ignored as Qt (and libpng) handles that error just fine at runtime. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3412
2016-11-18 09:02:04 +00:00
signal(SIGPIPE, SIG_IGN);
[kwin-wayland] Add signal handler also to main_wayland REVIEW: 119760
2014-08-13 11:13:44 +00:00
wayland: Bump RLIMIT_NOFILE limit As a wayland compositor kwin can hold many open file descriptors and therefore it's easier for it to hit the soft file descriptor limit. This change makes kwin_wayland bump the soft file descriptor limit to the hard limit. With systemd, it's usually 500K. In order to prevent causing mess in child processes, pthread_atfork() is used to register a handler which will be invoked in the child process after fork() in order to restore RLIMIT_NOFILE to its original value.
2022-05-15 13:22:35 +00:00
// It's easy to exceed the file descriptor limit because many things are backed using fds
// nowadays, e.g. dmabufs, shm buffers, etc. Bump the RLIMIT_NOFILE limit to handle that.
// Some apps may still use select(), so we reset the limit to its original value in fork().
if (KWin::bumpNofileLimit()) {
pthread_atfork(nullptr, nullptr, KWin::restoreNofileLimit);
}
[wayland] Improve passing env variables to applications started by KWin If an env variable is set outside of KWin (e.g. QT_QPA_PLATFORM) we want KWin to pass the original env variable to the started process and not pass none instead because it's one of KWin's special changed variables. Thus we take the environment before we adjust it and pass that to the started processes with our own DISPLAY and WAYLAND_DISPLAY added.
2015-06-29 08:51:37 +00:00
QProcessEnvironment environment = QProcessEnvironment::systemEnvironment();
[wayland] Enforce our internal QPA plugin as QT_QPA_PLATFORM
2015-08-18 06:05:08 +00:00
// enforce our internal qpa plugin, unfortunately command line switch has precedence
setenv("QT_QPA_PLATFORM", "wayland-org.kde.kwin.qpa", true);
[wayland] Enforce the wayland QPA This requires a change present in Qt 5.4.2, without the startup will freeze. A warning message is shown if the compiled Qt version is not at least 5.4.2. It's only a warning and an ifdef as distros might backport the required change.
2015-03-17 09:31:18 +00:00
Don't follow QT_DEVICE_PIXEL_RATIO Setting this means we get scaled screen geometry from Qt, and everything becomes confusing when commmunicating with apps that might not have this set. As we use plasma units for UI everything is scaled anyway. REVIEW: 123115
2015-04-17 16:13:39 +00:00
qunsetenv("QT_DEVICE_PIXEL_RATIO");
[wayland] Enforce basic render loop Looks like Qt 5.5 changed the default back to threaded and that can result in dead locks of the compositor. So better enforce to basic for the time being. Another reason to have an own QPA to get rid of these "regressions".
2015-07-10 06:57:56 +00:00
qputenv("QSG_RENDER_LOOP", "basic");
Add high DPI support to internal KWin windows Summary: So far we didn't try to do high DPI on kwin internal windows, such as the user context menu and tab bars and whatever. Due to wayland scaling they were the correct phyiscal size but upscaled. This patch fixes our QPA to enable Qt's high-dpi support. BUG: 402853 Note icons are still low res. This is because the global QGuiApplication::devicePixelRatio which is the max of all connected screens is static for the duration of the app. QIcon uses this when determining the DPR to use. This will require a Qt change. Test Plan: Ran at 2x on my normal DPI screen (as that's easier to see anything) * User action menu is high DPI * Window deco tooltips are still fine * Tab switcher is high DPI * Overlay in present windows Desktop grid are still ok Reviewers: #kwin Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18042
2019-01-11 22:48:04 +00:00
QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps);
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
KWin::ApplicationWayland a(argc, argv);
a.setupTranslator();
Don't force QT_QPA_PLATFORM=wayland We're setting this env variable because earlier we used it to force kwin to use its special QPA so we need to change that back to something sensible. However setting it to Wayland breaks apps that ship their own Qt with missing or broken Wayland support. Set it to be empty instead. Well-behaved Qt apps will use Wayland regardless because of XDG_SESSION_TYPE. BUG: 450000
2022-02-11 23:41:34 +00:00
// reset QT_QPA_PLATFORM so we don't propagate it to our children (e.g. apps launched from the overview effect)
qunsetenv("QT_QPA_PLATFORM");
Let the fun begin: start a WaylandServer in kwin_wayland The WaylandServer is at the moment only used to support starting an Xwayland. It does not support Wayland clients yet, so don't get excited. For Xwayland it's using the trick of creating the Display before the QApplication is created with manual event dispatching.
2015-02-09 12:28:37 +00:00
Fix handling of different signals (SIGTERM et al) by using KSignalHandler When debugging something I realised that SIGTERM was always making KWin crash like I'd never seen it crash. It turns out we are calling QApplication::exit() on the signal handler which is highly forbidden as the handler preempts the process altogether. Use KSignalHandler instead which takes this issue into account.
2022-09-15 15:18:44 +00:00
KSignalHandler::self()->watchSignal(SIGTERM);
KSignalHandler::self()->watchSignal(SIGINT);
KSignalHandler::self()->watchSignal(SIGHUP);
QObject::connect(KSignalHandler::self(), &KSignalHandler::signalReceived,
&a, &QCoreApplication::exit);
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
KWin::Application::createAboutData();
[xwayland] Add a dedicated --xwayland option to kwin_wayland The --xwayland option starts a rootles Xwayland server. If a rootless Xwayland server is used OperationModeXwayland is used which is introduced with this change as well.
2015-01-09 15:00:16 +00:00
QCommandLineOption xwaylandOption(QStringLiteral("xwayland"),
[xwayland] Drop options to start Xephyr or Xvfb Only --xwayland stays supported. The option --displayfd and --rootless are always set. Simplifies the feature matrix and the other X servers don't make any sense now that we can start a proper rootless Xwayland.
2015-02-09 12:40:01 +00:00
i18n("Start a rootless Xwayland server."));
Let the fun begin: start a WaylandServer in kwin_wayland The WaylandServer is at the moment only used to support starting an Xwayland. It does not support Wayland clients yet, so don't get excited. For Xwayland it's using the trick of creating the Display before the QApplication is created with manual event dispatching.
2015-02-09 12:28:37 +00:00
QCommandLineOption waylandSocketOption(QStringList{QStringLiteral("s"), QStringLiteral("socket")},
i18n("Name of the Wayland socket to listen on. If not set \"wayland-0\" is used."),
QStringLiteral("socket"));
[wayland] Add an X11 output backend This new backend allows to start a kwin_wayland server nested on an X-Server by using a normal X11 window as output. This allows testing kwin_wayland without needing to start another Wayland server first. The behavior is triggered by using new command line arguments: --windowed --x11-display=<:0> With optional --width and --height arguments. In this mode the WaylandBackend is not created at all. So far the backend is not fully integrated yet and only the QPainter backend supports this mode.
2015-03-19 07:29:34 +00:00
QCommandLineOption x11DisplayOption(QStringLiteral("x11-display"),
i18n("The X11 Display to use in windowed mode on platform X11."),
QStringLiteral("display"));
[wayland] Improve decision which backend to create Both Wayland and X11 backend are bound to the --windowed flag. Which one to create is decided whether DISPLAY or WAYLAND_DISPLAY env variables are set with Wayland having precedence over X11. Passing the display as command line argument overwrites the env variable and takes further precedence. E.g. if WAYLAND_DISPLAY is exported and --x11-display argument is provided, it will create X11 backend. Similarly there is now a --wayland-display command line argument. If no backend got created, kwin_wayland will exit. The singleton variant of WaylandBackend is adjusted to take the display as argument and pass it to the Connection.
2015-03-23 11:45:21 +00:00
QCommandLineOption waylandDisplayOption(QStringLiteral("wayland-display"),
i18n("The Wayland Display to use in windowed mode on platform Wayland."),
QStringLiteral("display"));
[wayland] Add a virtual framebuffer backend A new backend which doesn't present the rendered output. It uses a QPainter scene, renders to a QImage but doesn't present it anywhere. Thus a real virtual backend. By exporting the environment variable KWIN_WAYLAND_VIRTUAL_SCREENSHOTS the backend creates a temporary dir, prints the path to std-out and saves each rendered frame into that directory. Of course with exit it will be deleted again.
2015-10-02 08:44:29 +00:00
QCommandLineOption virtualFbOption(QStringLiteral("virtual"), i18n("Render to a virtual framebuffer."));
[wayland] Add an X11 output backend This new backend allows to start a kwin_wayland server nested on an X-Server by using a normal X11 window as output. This allows testing kwin_wayland without needing to start another Wayland server first. The behavior is triggered by using new command line arguments: --windowed --x11-display=<:0> With optional --width and --height arguments. In this mode the WaylandBackend is not created at all. So far the backend is not fully integrated yet and only the QPainter backend supports this mode.
2015-03-19 07:29:34 +00:00
QCommandLineOption widthOption(QStringLiteral("width"),
i18n("The width for windowed mode. Default width is 1024."),
QStringLiteral("width"));
widthOption.setDefaultValue(QString::number(1024));
QCommandLineOption heightOption(QStringLiteral("height"),
i18n("The height for windowed mode. Default height is 768."),
QStringLiteral("height"));
heightOption.setDefaultValue(QString::number(768));
Set wayland output scale Summary: Provides a virtual method in Screens where backends can supply the scale of each screen, this is then set on each output. For the X windowed backend this value is taken from a command line parameter. Test Plan: Ran windowed mode with --scale 1 and 2 then kate --platform=wayland from another screen. On the latter case UI elements were scaled up correctly Reviewers: #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D3159
2016-10-25 23:36:02 +00:00
QCommandLineOption scaleOption(QStringLiteral("scale"),
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
i18n("The scale for windowed mode. Default value is 1."),
QStringLiteral("scale"));
Set wayland output scale Summary: Provides a virtual method in Screens where backends can supply the scale of each screen, this is then set on each output. For the X windowed backend this value is taken from a command line parameter. Test Plan: Ran windowed mode with --scale 1 and 2 then kate --platform=wayland from another screen. On the latter case UI elements were scaled up correctly Reviewers: #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D3159
2016-10-25 23:36:02 +00:00
scaleOption.setDefaultValue(QString::number(1));
[wayland] Add support for initial output count for nested compositors Added to x11 backend which creates one window per output. New command line option is called --output-count=<int>.
2015-11-24 12:11:29 +00:00
QCommandLineOption outputCountOption(QStringLiteral("output-count"),
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
i18n("The number of windows to open as outputs in windowed mode. Default value is 1"),
QStringLiteral("count"));
[wayland] Add support for initial output count for nested compositors Added to x11 backend which creates one window per output. New command line option is called --output-count=<int>.
2015-11-24 12:11:29 +00:00
outputCountOption.setDefaultValue(QString::number(1));
[kwin_wayland] Add config option to start an X Server KWin_Wayland still needs an X-Server. To simplify the development setup the required X-Server can be started through a command line argument together with KWin. Unfortunately the command line arguments processing needs to be done by hand as QCommandLineParser only allows processing after QApplication is created which requires the started X Server. The nested X-Server is started by forking the application and using execlp to load the binary. In addition a pipe is created to allow the X-Server to write the display number to once it's ready to connect and by that KWin is ready to create the QApplication.
2014-08-12 13:27:35 +00:00
wayland: Rename wayland_fd arg to wayland-fd This make argument naming consistent, for example we have xwayland-fd arg, which has a dash instead of underscore.
2021-12-02 14:02:22 +00:00
QCommandLineOption waylandSocketFdOption(QStringLiteral("wayland-fd"),
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
i18n("Wayland socket to use for incoming connections. This can be combined with --socket to name the socket"),
QStringLiteral("wayland-fd"));
Introduce helper to restart kwin on crash exit Right now when kwin exits, the user is taken directly back to the login screen. The login session exits, so all processes then are killed by the session. This patchset introduces a mechanism to safely restart kwin. The socket (typically wayland-0) remains alive and persistent across restarts. This means if any process reconnects through it's own mechanism or a crash restart handler the socket appears to work, and blocks until the new kwin restarts. This makes it secure and race free. If the screen was locked at the time kwin went down, this is also secure. Kwin now checks the status from logind at the time of launch, so will immediately restore a locked state before any other rendering.
2020-11-17 18:09:28 +00:00
[kwin_wrapper] Transfer ownership of Xwayland socket creation and Xauthority to the wrapper This way if kwin_wayland crashes we don't need to ensure that new environment variables need to get synced across the new env. This fixes an issue where spawning an xwayland application from a wayland window that survives a crash would fail. By moving the logic here we no longer need to wait for kwin_wayland to start before starting plasmashell or even ksmserver as all environment variables are set. As long as the wrapper is ready we can continue starting and clients will just block on connect. That should still allow for both a lot of optimisations both for speed and cleaning up the startplasma-wayland scripts. This will be addressed in follow up patches. Use of kwin_wayland directly with xwayland is still supported for testing.
2021-07-28 10:03:10 +00:00
QCommandLineOption xwaylandListenFdOption(QStringLiteral("xwayland-fd"),
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
i18n("XWayland socket to use for Xwayland's incoming connections. This can be set multiple times"),
QStringLiteral("xwayland-fds"));
[kwin_wrapper] Transfer ownership of Xwayland socket creation and Xauthority to the wrapper This way if kwin_wayland crashes we don't need to ensure that new environment variables need to get synced across the new env. This fixes an issue where spawning an xwayland application from a wayland window that survives a crash would fail. By moving the logic here we no longer need to wait for kwin_wayland to start before starting plasmashell or even ksmserver as all environment variables are set. As long as the wrapper is ready we can continue starting and clients will just block on connect. That should still allow for both a lot of optimisations both for speed and cleaning up the startplasma-wayland scripts. This will be addressed in follow up patches. Use of kwin_wayland directly with xwayland is still supported for testing.
2021-07-28 10:03:10 +00:00
QCommandLineOption xwaylandDisplayOption(QStringLiteral("xwayland-display"),
i18n("Name of the xwayland display that has been pre-set up"),
"xwayland-display");
QCommandLineOption xwaylandXAuthorityOption(QStringLiteral("xwayland-xauthority"),
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
i18n("Name of the xauthority file "),
"xwayland-xauthority");
[kwin_wrapper] Transfer ownership of Xwayland socket creation and Xauthority to the wrapper This way if kwin_wayland crashes we don't need to ensure that new environment variables need to get synced across the new env. This fixes an issue where spawning an xwayland application from a wayland window that survives a crash would fail. By moving the logic here we no longer need to wait for kwin_wayland to start before starting plasmashell or even ksmserver as all environment variables are set. As long as the wrapper is ready we can continue starting and clients will just block on connect. That should still allow for both a lot of optimisations both for speed and cleaning up the startplasma-wayland scripts. This will be addressed in follow up patches. Use of kwin_wayland directly with xwayland is still supported for testing.
2021-07-28 10:03:10 +00:00
Make it possible to restart kwin_wayland from a command line argument A recent patch made it possible to restart KWin when it crashes, this opens the possibility to do it for development purposes. So far it could be done using `killall -9 kwin_wayland`. This patch embraces this functionality under --replace so it's a bit more documented and under its own semantics. It is done by returning the process with 133 exit code and picking that code specifically as a wish to restart.
2021-01-30 00:37:13 +00:00
QCommandLineOption replaceOption(QStringLiteral("replace"),
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
i18n("Exits this instance so it can be restarted by kwin_wayland_wrapper."));
Make it possible to restart kwin_wayland from a command line argument A recent patch made it possible to restart KWin when it crashes, this opens the possibility to do it for development purposes. So far it could be done using `killall -9 kwin_wayland`. This patch embraces this functionality under --replace so it's a bit more documented and under its own semantics. It is done by returning the process with 133 exit code and picking that code specifically as a wish to restart.
2021-01-30 00:37:13 +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
QCommandLineOption drmOption(QStringLiteral("drm"), i18n("Render through drm node."));
Include org.freedesktop.locale1 support Makes it possible to follow the dbus service for locale configuration, making it possible to have third parties integrate with Plasma. This is done opt-in for now, it can be adopted generally in the future, if necessary.
2022-09-08 22:18:12 +00:00
QCommandLineOption locale1Option(QStringLiteral("locale1"), i18n("Extract locale information from locale1 rather than the user's configuration"));
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
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
QCommandLineParser parser;
a.setupCommandLine(&parser);
[xwayland] Add a dedicated --xwayland option to kwin_wayland The --xwayland option starts a rootles Xwayland server. If a rootless Xwayland server is used OperationModeXwayland is used which is introduced with this change as well.
2015-01-09 15:00:16 +00:00
parser.addOption(xwaylandOption);
Let the fun begin: start a WaylandServer in kwin_wayland The WaylandServer is at the moment only used to support starting an Xwayland. It does not support Wayland clients yet, so don't get excited. For Xwayland it's using the trick of creating the Display before the QApplication is created with manual event dispatching.
2015-02-09 12:28:37 +00:00
parser.addOption(waylandSocketOption);
Introduce helper to restart kwin on crash exit Right now when kwin exits, the user is taken directly back to the login screen. The login session exits, so all processes then are killed by the session. This patchset introduces a mechanism to safely restart kwin. The socket (typically wayland-0) remains alive and persistent across restarts. This means if any process reconnects through it's own mechanism or a crash restart handler the socket appears to work, and blocks until the new kwin restarts. This makes it secure and race free. If the screen was locked at the time kwin went down, this is also secure. Kwin now checks the status from logind at the time of launch, so will immediately restore a locked state before any other rendering.
2020-11-17 18:09:28 +00:00
parser.addOption(waylandSocketFdOption);
[kwin_wrapper] Transfer ownership of Xwayland socket creation and Xauthority to the wrapper This way if kwin_wayland crashes we don't need to ensure that new environment variables need to get synced across the new env. This fixes an issue where spawning an xwayland application from a wayland window that survives a crash would fail. By moving the logic here we no longer need to wait for kwin_wayland to start before starting plasmashell or even ksmserver as all environment variables are set. As long as the wrapper is ready we can continue starting and clients will just block on connect. That should still allow for both a lot of optimisations both for speed and cleaning up the startplasma-wayland scripts. This will be addressed in follow up patches. Use of kwin_wayland directly with xwayland is still supported for testing.
2021-07-28 10:03:10 +00:00
parser.addOption(xwaylandListenFdOption);
parser.addOption(xwaylandDisplayOption);
parser.addOption(xwaylandXAuthorityOption);
Make it possible to restart kwin_wayland from a command line argument A recent patch made it possible to restart KWin when it crashes, this opens the possibility to do it for development purposes. So far it could be done using `killall -9 kwin_wayland`. This patch embraces this functionality under --replace so it's a bit more documented and under its own semantics. It is done by returning the process with 133 exit code and picking that code specifically as a wish to restart.
2021-01-30 00:37:13 +00:00
parser.addOption(replaceOption);
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
parser.addOption(x11DisplayOption);
parser.addOption(waylandDisplayOption);
parser.addOption(virtualFbOption);
parser.addOption(widthOption);
parser.addOption(heightOption);
parser.addOption(scaleOption);
parser.addOption(outputCountOption);
parser.addOption(drmOption);
Include org.freedesktop.locale1 support Makes it possible to follow the dbus service for locale configuration, making it possible to have third parties integrate with Plasma. This is done opt-in for now, it can be adopted generally in the future, if necessary.
2022-09-08 22:18:12 +00:00
parser.addOption(locale1Option);
[wayland] Add a command-line option to start an input method server Input-method servers, like maliit, need to be known to KWin since KWin needs to know about virtual keyboards. Virtual keyboards should be shown as OSD layers, and they are one of the types of windows that actually should be showable when the lock screen is active. kwin_wayland --inputmethod /path/to/your/input-server tries to start the input server. The input-server's window never gets keyboard focus and is shown on top of all windows except for KWin's internal clients.
2015-06-13 02:06:12 +00:00
QCommandLineOption inputMethodOption(QStringLiteral("inputmethod"),
i18n("Input method that KWin starts."),
QStringLiteral("path/to/imserver"));
parser.addOption(inputMethodOption);
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_SCREENLOCKER
[wayland] Start ksldapp from the WaylandServer This introduces --lockscreen option in kwin_wayland which when used will lock screen immediately. Also dependency to newly created kscreenlocker repo is introduced. REVIEW: 125954
2015-11-05 13:09:23 +00:00
QCommandLineOption screenLockerOption(QStringLiteral("lockscreen"),
i18n("Starts the session in locked mode."));
parser.addOption(screenLockerOption);
Add command line option no-lockscreen to disable lock screen integration Summary: WaylandServer provides the initialization flag to disable lock screen integration. This couldn't be used yet as there is no command line flag for it. This change adds a new command line argument and hooks up the functionality. The no lock screen integration is useful for the embedded use case where KWin is just used to render one application. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17279
2018-12-01 12:17:02 +00:00
QCommandLineOption noScreenLockerOption(QStringLiteral("no-lockscreen"),
i18n("Starts the session without lock screen support."));
parser.addOption(noScreenLockerOption);
Add KWIN_BUILD_SCREENLOCKER option Allows to build KWin without lockscreen support and thus drops the kscreenlocker dependency. Signed-off-by: Eike Hein <eike.hein@mbition.io>
2022-02-23 13:27:05 +00:00
#endif
Add command line option no-lockscreen to disable lock screen integration Summary: WaylandServer provides the initialization flag to disable lock screen integration. This couldn't be used yet as there is no command line flag for it. This change adds a new command line argument and hooks up the functionality. The no lock screen integration is useful for the embedded use case where KWin is just used to render one application. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17279
2018-12-01 12:17:02 +00:00
Introduce a command line option to disable any kind of global shortcuts Summary: This command line option is useful for KWin in embedded use case. That is when KWin is just used as a compositor for one application instead of a complete desktop environment. In such a setup global shortcuts are not wanted and interfere with the application. E.g. one does not want Alt+F4 to close the window, that would render the system unusable. This change introduces a command line option and disables the following event filters and spies: * global shortcuts * modifier only shortcuts * terminate session * virtual terminal switching * screen edges KGlobalAccel still gets inited, otherwise the (non-functional) binary would be launched when KWin registers it's global shortcuts. Test Plan: New test added based on existing tests for the global shortcuts, ctest passes Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17304
2018-12-02 12:09:37 +00:00
QCommandLineOption noGlobalShortcutsOption(QStringLiteral("no-global-shortcuts"),
i18n("Starts the session without global shortcuts support."));
Fix --no-global-shortcuts option Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18643
2019-02-01 14:29:04 +00:00
parser.addOption(noGlobalShortcutsOption);
Introduce a command line option to disable any kind of global shortcuts Summary: This command line option is useful for KWin in embedded use case. That is when KWin is just used as a compositor for one application instead of a complete desktop environment. In such a setup global shortcuts are not wanted and interfere with the application. E.g. one does not want Alt+F4 to close the window, that would render the system unusable. This change introduces a command line option and disables the following event filters and spies: * global shortcuts * modifier only shortcuts * terminate session * virtual terminal switching * screen edges KGlobalAccel still gets inited, otherwise the (non-functional) binary would be launched when KWin registers it's global shortcuts. Test Plan: New test added based on existing tests for the global shortcuts, ctest passes Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17304
2018-12-02 12:09:37 +00:00
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
Enable KActivities integration by default in kwin_wayland
2021-03-05 12:52:58 +00:00
QCommandLineOption noActivitiesOption(QStringLiteral("no-kactivities"),
i18n("Disable KActivities integration."));
parser.addOption(noActivitiesOption);
#endif
[wayland] Introduce an additional --exit-with-session command line arg This is similar to the applications to start. That is the value of the command line argument is interpreted as a command to start. The difference is that when this application exits, KWin will also quit. The argument is so to say interpreted as a session. Reviewed-By: Bhushan Shah
2015-11-19 08:16:23 +00:00
QCommandLineOption exitWithSessionOption(QStringLiteral("exit-with-session"),
i18n("Exit after the session application, which is started by KWin, closed."),
QStringLiteral("/path/to/session"));
parser.addOption(exitWithSessionOption);
[wayland] Add positional arguments to be programs to starts This allows to start applications once kwin_wayland is started. E.g. kwin_wayland --libinput --xwayland --framebuffer /usr/bin/startkde Thus it would start startkde once both Wayland Server and Xwayland are up and running and ready for connection. This resolves the problem that prior to startup it is not known which will be the X11 display variable. By passing the environment to the process by KWin this problem is resolved.
2015-04-21 09:21:28 +00:00
parser.addPositionalArgument(QStringLiteral("applications"),
i18n("Applications to start once Wayland and Xwayland server are started"),
QStringLiteral("[/path/to/application...]"));
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
parser.process(a);
a.processCommandLine(&parser);
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
Enable KActivities integration by default in kwin_wayland
2021-03-05 12:52:58 +00:00
if (parser.isSet(noActivitiesOption)) {
a.setUseKActivities(false);
}
Introduce a --no-kactivities command line option This change enables kactivities integration by default again on both X11 and Wayland (as kactivities no longer blocks). As we have an infrastructure to disable kactivities we can also make use of it and offer a command line switch to disable kactivities. This might be useful for using KWin outside of Plasma. REVIEW: 126153
2015-11-24 08:01:46 +00:00
#endif
Make it possible to restart kwin_wayland from a command line argument A recent patch made it possible to restart KWin when it crashes, this opens the possibility to do it for development purposes. So far it could be done using `killall -9 kwin_wayland`. This patch embraces this functionality under --replace so it's a bit more documented and under its own semantics. It is done by returning the process with 133 exit code and picking that code specifically as a wish to restart.
2021-01-30 00:37:13 +00:00
if (parser.isSet(replaceOption)) {
QDBusMessage msg = QDBusMessage::createMethodCall(QStringLiteral("org.kde.KWin"), QStringLiteral("/KWin"),
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
QStringLiteral("org.kde.KWin"), QStringLiteral("replace"));
Make it possible to restart kwin_wayland from a command line argument A recent patch made it possible to restart KWin when it crashes, this opens the possibility to do it for development purposes. So far it could be done using `killall -9 kwin_wayland`. This patch embraces this functionality under --replace so it's a bit more documented and under its own semantics. It is done by returning the process with 133 exit code and picking that code specifically as a wish to restart.
2021-01-30 00:37:13 +00:00
QDBusConnection::sessionBus().call(msg, QDBus::NoBlock);
return 0;
}
[wayland] Add a --list-backends command line arg for listing available backends Distributions do package each backend plugin in a dedicated package, which means just because KWin got compiled with a specific backend, doesn't mean it is also available at runtime. In order to better support this reality this change introduces a list-backends command line option. Each of the plugins got the json metadata extended by the KPlugin syntax, so that we have a name and description to print. As we already locate all plugins anyway, the additional findPlugins for the selected backend is changed to search the list of all plugin meta data.
2015-10-02 07:31:47 +00:00
[wayland] Introduce an additional --exit-with-session command line arg This is similar to the applications to start. That is the value of the command line argument is interpreted as a command to start. The difference is that when this application exits, KWin will also quit. The argument is so to say interpreted as a session. Reviewed-By: Bhushan Shah
2015-11-19 08:16:23 +00:00
if (parser.isSet(exitWithSessionOption)) {
a.setSessionArgument(parser.value(exitWithSessionOption));
}
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
enum class BackendType {
Kms,
X11,
Wayland,
Virtual,
};
BackendType backendType;
Create a plugin for each of the wayland backends Each of the backends becomes a plugin. This allows kwin_wayland to load the requested plugin and kwin itself doesn't need to link all the libraries needed. E.g. libdrm is no longer linked if running kwin_x11. Also this allows to create backends for the non-standard EGL platforms (examples could be raspberrypi or Android devices).
2015-05-05 15:58:09 +00:00
QString pluginName;
QSize initialWindowSize;
[wayland] Add support for initial output count for nested compositors Added to x11 backend which creates one window per output. New command line option is called --output-count=<int>.
2015-11-24 12:11:29 +00:00
int outputCount = 1;
Set wayland output scale Summary: Provides a virtual method in Screens where backends can supply the scale of each screen, this is then set on each output. For the X windowed backend this value is taken from a command line parameter. Test Plan: Ran windowed mode with --scale 1 and 2 then kate --platform=wayland from another screen. On the latter case UI elements were scaled up correctly Reviewers: #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D3159
2016-10-25 23:36:02 +00:00
qreal outputScale = 1;
[wayland] Rework command line checks for platforms The change to reflect the available plugins in the command line options had side effects as that made it impossible to start KWin if certain plugins are not available. This change ensures that we only check the option value if they are set in the first place. In addition the multi checks to verify whether combinations are valid is removed as that makes in reality no sense any more (only few plugins installed by distros) and doesn't scale any more with the increasing numbers of backends.
2015-10-03 18:14:16 +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
// Decide what backend to use.
if (parser.isSet(drmOption)) {
backendType = BackendType::Kms;
} else if (parser.isSet(x11DisplayOption)) {
backendType = BackendType::X11;
} else if (parser.isSet(waylandDisplayOption)) {
backendType = BackendType::Wayland;
} else if (parser.isSet(virtualFbOption)) {
backendType = BackendType::Virtual;
} else {
if (qEnvironmentVariableIsSet("WAYLAND_DISPLAY")) {
wayland: print warning about automatic backend selection BUG: 457491
2022-08-04 19:23:47 +00:00
qWarning("No backend specified, automatically choosing Wayland because WAYLAND_DISPLAY is set");
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
backendType = BackendType::Wayland;
} else if (qEnvironmentVariableIsSet("DISPLAY")) {
wayland: print warning about automatic backend selection BUG: 457491
2022-08-04 19:23:47 +00:00
qWarning("No backend specified, automatically choosing X11 because DISPLAY is set");
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
backendType = BackendType::X11;
} else {
wayland: print warning about automatic backend selection BUG: 457491
2022-08-04 19:23:47 +00:00
qWarning("No backend specified, automatically choosing drm");
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
backendType = BackendType::Kms;
Set wayland output scale Summary: Provides a virtual method in Screens where backends can supply the scale of each screen, this is then set on each output. For the X windowed backend this value is taken from a command line parameter. Test Plan: Ran windowed mode with --scale 1 and 2 then kate --platform=wayland from another screen. On the latter case UI elements were scaled up correctly Reviewers: #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D3159
2016-10-25 23:36:02 +00:00
}
[wayland] Introduce automatic backend selection If none of the backend specific command line options are passed, we try to autmatically determine the proper plugin. 1. if DISPLAY is set -> x11 backend 2. if WAYLAND_DISPLAY is set -> wayland backend 3. if compiled with libhybris and ANDROID_ROOT is set -> hwcomposer backend 4. if compiled with DRM -> drm backend 5. if nothing selected yet, fallback to fbdev
2015-06-29 09:59:27 +00:00
}
Include org.freedesktop.locale1 support Makes it possible to follow the dbus service for locale configuration, making it possible to have third parties integrate with Plasma. This is done opt-in for now, it can be adopted generally in the future, if necessary.
2022-09-08 22:18:12 +00:00
if (parser.isSet(locale1Option)) {
a.setFollowLocale1(true);
}
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
bool ok = false;
const int width = parser.value(widthOption).toInt(&ok);
if (!ok) {
std::cerr << "FATAL ERROR incorrect value for width" << std::endl;
return 1;
[wayland] Add support for initial output count for nested compositors Added to x11 backend which creates one window per output. New command line option is called --output-count=<int>.
2015-11-24 12:11:29 +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
const int height = parser.value(heightOption).toInt(&ok);
if (!ok) {
std::cerr << "FATAL ERROR incorrect value for height" << std::endl;
return 1;
[wayland] Add an X11 output backend This new backend allows to start a kwin_wayland server nested on an X-Server by using a normal X11 window as output. This allows testing kwin_wayland without needing to start another Wayland server first. The behavior is triggered by using new command line arguments: --windowed --x11-display=<:0> With optional --width and --height arguments. In this mode the WaylandBackend is not created at all. So far the backend is not fully integrated yet and only the QPainter backend supports this mode.
2015-03-19 07:29:34 +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
const qreal scale = parser.value(scaleOption).toDouble(&ok);
if (!ok || scale <= 0) {
std::cerr << "FATAL ERROR incorrect value for scale" << std::endl;
return 1;
[wayland] Add a virtual framebuffer backend A new backend which doesn't present the rendered output. It uses a QPainter scene, renders to a QImage but doesn't present it anywhere. Thus a real virtual backend. By exporting the environment variable KWIN_WAYLAND_VIRTUAL_SCREENSHOTS the backend creates a temporary dir, prints the path to std-out and saves each rendered frame into that directory. Of course with exit it will be deleted again.
2015-10-02 08:44:29 +00:00
}
Create a plugin for each of the wayland backends Each of the backends becomes a plugin. This allows kwin_wayland to load the requested plugin and kwin itself doesn't need to link all the libraries needed. E.g. libdrm is no longer linked if running kwin_x11. Also this allows to create backends for the non-standard EGL platforms (examples could be raspberrypi or Android devices).
2015-05-05 15:58:09 +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
outputScale = scale;
initialWindowSize = QSize(width, height);
[wayland] Introduce automatic backend selection If none of the backend specific command line options are passed, we try to autmatically determine the proper plugin. 1. if DISPLAY is set -> x11 backend 2. if WAYLAND_DISPLAY is set -> wayland backend 3. if compiled with libhybris and ANDROID_ROOT is set -> hwcomposer backend 4. if compiled with DRM -> drm backend 5. if nothing selected yet, fallback to fbdev
2015-06-29 09:59:27 +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
const int count = parser.value(outputCountOption).toInt(&ok);
if (ok) {
qMax -> std::max
2022-11-12 14:25:23 +00:00
outputCount = std::max(1, count);
Create a plugin for each of the wayland backends Each of the backends becomes a plugin. This allows kwin_wayland to load the requested plugin and kwin itself doesn't need to link all the libraries needed. E.g. libdrm is no longer linked if running kwin_x11. Also this allows to create backends for the non-standard EGL platforms (examples could be raspberrypi or Android devices).
2015-05-05 15:58:09 +00:00
}
[wayland] Create waylandServer after creating QApplication Our QPA plugin does not require a running Wayland server at startup, so we can move the startup after creating the application. Nice side effect: --help works now.
2015-08-20 10:54:23 +00:00
// TODO: create backend without having the server running
KWin::WaylandServer *server = KWin::WaylandServer::create(&a);
[wayland] Start ksldapp from the WaylandServer This introduces --lockscreen option in kwin_wayland which when used will lock screen immediately. Also dependency to newly created kscreenlocker repo is introduced. REVIEW: 125954
2015-11-05 13:09:23 +00:00
Fix minor typo: inital -> initial Summary: inital -> initial Test Plan: none Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28092
2020-03-17 05:48:05 +00:00
KWin::WaylandServer::InitializationFlags flags;
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_SCREENLOCKER
[wayland] Start ksldapp from the WaylandServer This introduces --lockscreen option in kwin_wayland which when used will lock screen immediately. Also dependency to newly created kscreenlocker repo is introduced. REVIEW: 125954
2015-11-05 13:09:23 +00:00
if (parser.isSet(screenLockerOption)) {
Fix minor typo: inital -> initial Summary: inital -> initial Test Plan: none Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28092
2020-03-17 05:48:05 +00:00
flags = KWin::WaylandServer::InitializationFlag::LockScreen;
Add command line option no-lockscreen to disable lock screen integration Summary: WaylandServer provides the initialization flag to disable lock screen integration. This couldn't be used yet as there is no command line flag for it. This change adds a new command line argument and hooks up the functionality. The no lock screen integration is useful for the embedded use case where KWin is just used to render one application. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17279
2018-12-01 12:17:02 +00:00
} else if (parser.isSet(noScreenLockerOption)) {
Fix minor typo: inital -> initial Summary: inital -> initial Test Plan: none Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28092
2020-03-17 05:48:05 +00:00
flags = KWin::WaylandServer::InitializationFlag::NoLockScreenIntegration;
[wayland] Start ksldapp from the WaylandServer This introduces --lockscreen option in kwin_wayland which when used will lock screen immediately. Also dependency to newly created kscreenlocker repo is introduced. REVIEW: 125954
2015-11-05 13:09:23 +00:00
}
Add KWIN_BUILD_SCREENLOCKER option Allows to build KWin without lockscreen support and thus drops the kscreenlocker dependency. Signed-off-by: Eike Hein <eike.hein@mbition.io>
2022-02-23 13:27:05 +00:00
#endif
Introduce a command line option to disable any kind of global shortcuts Summary: This command line option is useful for KWin in embedded use case. That is when KWin is just used as a compositor for one application instead of a complete desktop environment. In such a setup global shortcuts are not wanted and interfere with the application. E.g. one does not want Alt+F4 to close the window, that would render the system unusable. This change introduces a command line option and disables the following event filters and spies: * global shortcuts * modifier only shortcuts * terminate session * virtual terminal switching * screen edges KGlobalAccel still gets inited, otherwise the (non-functional) binary would be launched when KWin registers it's global shortcuts. Test Plan: New test added based on existing tests for the global shortcuts, ctest passes Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17304
2018-12-02 12:09:37 +00:00
if (parser.isSet(noGlobalShortcutsOption)) {
Fix minor typo: inital -> initial Summary: inital -> initial Test Plan: none Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D28092
2020-03-17 05:48:05 +00:00
flags |= KWin::WaylandServer::InitializationFlag::NoGlobalShortcuts;
Introduce a command line option to disable any kind of global shortcuts Summary: This command line option is useful for KWin in embedded use case. That is when KWin is just used as a compositor for one application instead of a complete desktop environment. In such a setup global shortcuts are not wanted and interfere with the application. E.g. one does not want Alt+F4 to close the window, that would render the system unusable. This change introduces a command line option and disables the following event filters and spies: * global shortcuts * modifier only shortcuts * terminate session * virtual terminal switching * screen edges KGlobalAccel still gets inited, otherwise the (non-functional) binary would be launched when KWin registers it's global shortcuts. Test Plan: New test added based on existing tests for the global shortcuts, ctest passes Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D17304
2018-12-02 12:09:37 +00:00
}
Introduce helper to restart kwin on crash exit Right now when kwin exits, the user is taken directly back to the login screen. The login session exits, so all processes then are killed by the session. This patchset introduces a mechanism to safely restart kwin. The socket (typically wayland-0) remains alive and persistent across restarts. This means if any process reconnects through it's own mechanism or a crash restart handler the socket appears to work, and blocks until the new kwin restarts. This makes it secure and race free. If the screen was locked at the time kwin went down, this is also secure. Kwin now checks the status from logind at the time of launch, so will immediately restore a locked state before any other rendering.
2020-11-17 18:09:28 +00:00
[kwin_wrapper] pass the wayland socket name via arguments rather than the env The initial goal of kwin_wrapper was that it would set up all relevant environment variables that will be used by the clients of kwin. This meant having to cache old variables before we overrode them and pass additional settings to the backends for the old wayland_display. It works, but with X11 about to move too ends up being unnecessarily complex. In hindsight it's easier for kwin to have the environment represent the platform it is currently on, and have kwin explicitly set variables in the QProcessEnvironment of the session it forks itnto. This patch is changed so that we set the wayland socket name used by the wrapper explicitly which is then used by the process environment kwin uses for the main session.
2021-08-16 16:38:02 +00:00
const QString socketName = parser.value(waylandSocketOption);
Introduce helper to restart kwin on crash exit Right now when kwin exits, the user is taken directly back to the login screen. The login session exits, so all processes then are killed by the session. This patchset introduces a mechanism to safely restart kwin. The socket (typically wayland-0) remains alive and persistent across restarts. This means if any process reconnects through it's own mechanism or a crash restart handler the socket appears to work, and blocks until the new kwin restarts. This makes it secure and race free. If the screen was locked at the time kwin went down, this is also secure. Kwin now checks the status from logind at the time of launch, so will immediately restore a locked state before any other rendering.
2020-11-17 18:09:28 +00:00
if (parser.isSet(waylandSocketFdOption)) {
bool ok;
int fd = parser.value(waylandSocketFdOption).toInt(&ok);
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
if (ok) {
Introduce helper to restart kwin on crash exit Right now when kwin exits, the user is taken directly back to the login screen. The login session exits, so all processes then are killed by the session. This patchset introduces a mechanism to safely restart kwin. The socket (typically wayland-0) remains alive and persistent across restarts. This means if any process reconnects through it's own mechanism or a crash restart handler the socket appears to work, and blocks until the new kwin restarts. This makes it secure and race free. If the screen was locked at the time kwin went down, this is also secure. Kwin now checks the status from logind at the time of launch, so will immediately restore a locked state before any other rendering.
2020-11-17 18:09:28 +00:00
// make sure we don't leak this FD to children
fcntl(fd, F_SETFD, O_CLOEXEC);
[kwin_wrapper] pass the wayland socket name via arguments rather than the env The initial goal of kwin_wrapper was that it would set up all relevant environment variables that will be used by the clients of kwin. This meant having to cache old variables before we overrode them and pass additional settings to the backends for the old wayland_display. It works, but with X11 about to move too ends up being unnecessarily complex. In hindsight it's easier for kwin to have the environment represent the platform it is currently on, and have kwin explicitly set variables in the QProcessEnvironment of the session it forks itnto. This patch is changed so that we set the wayland socket name used by the wrapper explicitly which is then used by the process environment kwin uses for the main session.
2021-08-16 16:38:02 +00:00
server->display()->addSocketFileDescriptor(fd, socketName);
Introduce helper to restart kwin on crash exit Right now when kwin exits, the user is taken directly back to the login screen. The login session exits, so all processes then are killed by the session. This patchset introduces a mechanism to safely restart kwin. The socket (typically wayland-0) remains alive and persistent across restarts. This means if any process reconnects through it's own mechanism or a crash restart handler the socket appears to work, and blocks until the new kwin restarts. This makes it secure and race free. If the screen was locked at the time kwin went down, this is also secure. Kwin now checks the status from logind at the time of launch, so will immediately restore a locked state before any other rendering.
2020-11-17 18:09:28 +00:00
} else {
std::cerr << "FATAL ERROR: could not parse socket FD" << std::endl;
return 1;
}
} else {
[kwin_wrapper] pass the wayland socket name via arguments rather than the env The initial goal of kwin_wrapper was that it would set up all relevant environment variables that will be used by the clients of kwin. This meant having to cache old variables before we overrode them and pass additional settings to the backends for the old wayland_display. It works, but with X11 about to move too ends up being unnecessarily complex. In hindsight it's easier for kwin to have the environment represent the platform it is currently on, and have kwin explicitly set variables in the QProcessEnvironment of the session it forks itnto. This patch is changed so that we set the wayland socket name used by the wrapper explicitly which is then used by the process environment kwin uses for the main session.
2021-08-16 16:38:02 +00:00
// socketName empty is fine here, addSocketName will automatically pick one
Introduce helper to restart kwin on crash exit Right now when kwin exits, the user is taken directly back to the login screen. The login session exits, so all processes then are killed by the session. This patchset introduces a mechanism to safely restart kwin. The socket (typically wayland-0) remains alive and persistent across restarts. This means if any process reconnects through it's own mechanism or a crash restart handler the socket appears to work, and blocks until the new kwin restarts. This makes it secure and race free. If the screen was locked at the time kwin went down, this is also secure. Kwin now checks the status from logind at the time of launch, so will immediately restore a locked state before any other rendering.
2020-11-17 18:09:28 +00:00
if (!server->display()->addSocketName(socketName)) {
std::cerr << "FATAL ERROR: could not add wayland socket " << qPrintable(socketName) << std::endl;
return 1;
}
}
if (!server->init(flags)) {
Handle situation of no XDG_RUNTIME_DIR gracefully Summary: If KWin fails to start the Wayland server due to XDG_RUNTIME_DIR not being set, kwin_wayland should terminate with an error condition but not crash. This change makes sure that KWin detects that the Wayland server does not work and terminates the startup early and ensures that it doesn't crash while going down. An error message is shown that we could not create the Wayland server. Test Plan: Test case added which verifies that WaylandServer fails to init. Manual testing that kwin_wayland exits with error 1. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2078
2016-07-04 07:09:03 +00:00
std::cerr << "FATAL ERROR: could not create Wayland server" << std::endl;
return 1;
}
[wayland] Create waylandServer after creating QApplication Our QPA plugin does not require a running Wayland server at startup, so we can move the startup after creating the application. Nice side effect: --help works now.
2015-08-20 10:54:23 +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
switch (backendType) {
case BackendType::Kms:
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
a.setSession(KWin::Session::create());
if (!a.session()) {
std::cerr << "FATAl ERROR: could not acquire a session" << std::endl;
return 1;
}
core: Rename Platform to OutputBackend
2022-11-05 10:43:41 +00:00
a.setOutputBackend(std::make_unique<KWin::DrmBackend>(a.session()));
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
break;
wayland: Make kwin_wayland create virtual outputs At the moment, we rely on placeholder output getting created, but there are cases where it's desired to spin kwin with virtual outputs so you could take screenshots and things as such.
2022-12-06 13:20:43 +00:00
case BackendType::Virtual: {
auto outputBackend = std::make_unique<KWin::VirtualBackend>();
for (int i = 0; i < outputCount; ++i) {
outputBackend->addOutput(initialWindowSize, outputScale);
}
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
a.setSession(KWin::Session::create(KWin::Session::Type::Noop));
wayland: Make kwin_wayland create virtual outputs At the moment, we rely on placeholder output getting created, but there are cases where it's desired to spin kwin with virtual outputs so you could take screenshots and things as such.
2022-12-06 13:20:43 +00:00
a.setOutputBackend(std::move(outputBackend));
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
break;
wayland: Make kwin_wayland create virtual outputs At the moment, we rely on placeholder output getting created, but there are cases where it's desired to spin kwin with virtual outputs so you could take screenshots and things as such.
2022-12-06 13:20:43 +00:00
}
backends/{x11,wayland}: Rework passing initial configuration to windowed backends Currently, OutputBackend stores the initial state for windowed backends. It's messy because the backends can have different needs. Instead, make windowed backends take an Options struct with all possible options.
2022-11-16 20:42:02 +00:00
case BackendType::X11: {
QString display = parser.value(x11DisplayOption);
if (display.isEmpty()) {
display = qgetenv("DISPLAY");
backends/wayland: Linearize startup sequence This change removes async bits from the startup code in the wayland backend to make it simpler. The main motivation behind this change is to refactor the wayland backend so OutputBackend::isReady() can be removed.
2022-11-10 19:07:54 +00:00
}
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
a.setSession(KWin::Session::create(KWin::Session::Type::Noop));
backends/{x11,wayland}: Rework passing initial configuration to windowed backends Currently, OutputBackend stores the initial state for windowed backends. It's messy because the backends can have different needs. Instead, make windowed backends take an Options struct with all possible options.
2022-11-16 20:42:02 +00:00
a.setOutputBackend(std::make_unique<KWin::X11WindowedBackend>(KWin::X11WindowedBackendOptions{
.display = display,
.outputCount = outputCount,
.outputScale = outputScale,
.outputSize = initialWindowSize,
}));
break;
}
case BackendType::Wayland: {
QString socketName = parser.value(waylandDisplayOption);
if (socketName.isEmpty()) {
socketName = qgetenv("WAYLAND_DISPLAY");
backends/wayland: Linearize startup sequence This change removes async bits from the startup code in the wayland backend to make it simpler. The main motivation behind this change is to refactor the wayland backend so OutputBackend::isReady() can be removed.
2022-11-10 19:07:54 +00:00
}
backends/{x11,wayland}: Rework passing initial configuration to windowed backends Currently, OutputBackend stores the initial state for windowed backends. It's messy because the backends can have different needs. Instead, make windowed backends take an Options struct with all possible options.
2022-11-16 20:42:02 +00:00
a.setSession(KWin::Session::create(KWin::Session::Type::Noop));
a.setOutputBackend(std::make_unique<KWin::Wayland::WaylandBackend>(KWin::Wayland::WaylandBackendOptions{
.socketName = socketName,
.outputCount = outputCount,
.outputScale = outputScale,
.outputSize = initialWindowSize,
}));
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
break;
Create a plugin for each of the wayland backends Each of the backends becomes a plugin. This allows kwin_wayland to load the requested plugin and kwin itself doesn't need to link all the libraries needed. E.g. libdrm is no longer linked if running kwin_x11. Also this allows to create backends for the non-standard EGL platforms (examples could be raspberrypi or Android devices).
2015-05-05 15:58:09 +00:00
}
[wayland] Add a framebuffer backend The framebuffer backend currently only supports the QPainter backend if the format matches RGB32. It does not yet support any cursors.
2015-03-31 09:00:46 +00:00
}
[wayland] Add an X11 output backend This new backend allows to start a kwin_wayland server nested on an X-Server by using a normal X11 window as output. This allows testing kwin_wayland without needing to start another Wayland server first. The behavior is triggered by using new command line arguments: --windowed --x11-display=<:0> With optional --width and --height arguments. In this mode the WaylandBackend is not created at all. So far the backend is not fully integrated yet and only the QPainter backend supports this mode.
2015-03-19 07:29:34 +00:00
[wayland] Add support for PlasmaWindowManagement interface So far this only allows to trigger show desktop functionality and exports the state. In future this should be restricted to just one dedicated desktop shell process.
2015-06-12 23:48:11 +00:00
QObject::connect(&a, &KWin::Application::workspaceCreated, server, &KWin::WaylandServer::initWorkspace);
Introduce helper to restart kwin on crash exit Right now when kwin exits, the user is taken directly back to the login screen. The login session exits, so all processes then are killed by the session. This patchset introduces a mechanism to safely restart kwin. The socket (typically wayland-0) remains alive and persistent across restarts. This means if any process reconnects through it's own mechanism or a crash restart handler the socket appears to work, and blocks until the new kwin restarts. This makes it secure and race free. If the screen was locked at the time kwin went down, this is also secure. Kwin now checks the status from logind at the time of launch, so will immediately restore a locked state before any other rendering.
2020-11-17 18:09:28 +00:00
if (!server->socketName().isEmpty()) {
environment.insert(QStringLiteral("WAYLAND_DISPLAY"), server->socketName());
Export our nested environment to kwin's env In the recent refactor we made it so environment variables got synced to the Application::processStartupEnvironment. It then seemed safe and cleaner to remove the qputenv calls, but this was not the case. It regressed the unit tests on CI and kglobalaccel which is another path where kwin spawns clients.
2021-08-19 09:09:24 +00:00
qputenv("WAYLAND_DISPLAY", server->socketName().toUtf8());
Introduce helper to restart kwin on crash exit Right now when kwin exits, the user is taken directly back to the login screen. The login session exits, so all processes then are killed by the session. This patchset introduces a mechanism to safely restart kwin. The socket (typically wayland-0) remains alive and persistent across restarts. This means if any process reconnects through it's own mechanism or a crash restart handler the socket appears to work, and blocks until the new kwin restarts. This makes it secure and race free. If the screen was locked at the time kwin went down, this is also secure. Kwin now checks the status from logind at the time of launch, so will immediately restore a locked state before any other rendering.
2020-11-17 18:09:28 +00:00
}
[wayland] Create waylandServer after creating QApplication Our QPA plugin does not require a running Wayland server at startup, so we can move the startup after creating the application. Nice side effect: --help works now.
2015-08-20 10:54:23 +00:00
a.setProcessStartupEnvironment(environment);
[kwin_wrapper] Transfer ownership of Xwayland socket creation and Xauthority to the wrapper This way if kwin_wayland crashes we don't need to ensure that new environment variables need to get synced across the new env. This fixes an issue where spawning an xwayland application from a wayland window that survives a crash would fail. By moving the logic here we no longer need to wait for kwin_wayland to start before starting plasmashell or even ksmserver as all environment variables are set. As long as the wrapper is ready we can continue starting and clients will just block on connect. That should still allow for both a lot of optimisations both for speed and cleaning up the startplasma-wayland scripts. This will be addressed in follow up patches. Use of kwin_wayland directly with xwayland is still supported for testing.
2021-07-28 10:03:10 +00:00
if (parser.isSet(xwaylandOption)) {
a.setStartXwayland(true);
if (parser.isSet(xwaylandListenFdOption)) {
const QStringList fdStrings = parser.values(xwaylandListenFdOption);
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
for (const QString &fdString : fdStrings) {
[kwin_wrapper] Transfer ownership of Xwayland socket creation and Xauthority to the wrapper This way if kwin_wayland crashes we don't need to ensure that new environment variables need to get synced across the new env. This fixes an issue where spawning an xwayland application from a wayland window that survives a crash would fail. By moving the logic here we no longer need to wait for kwin_wayland to start before starting plasmashell or even ksmserver as all environment variables are set. As long as the wrapper is ready we can continue starting and clients will just block on connect. That should still allow for both a lot of optimisations both for speed and cleaning up the startplasma-wayland scripts. This will be addressed in follow up patches. Use of kwin_wayland directly with xwayland is still supported for testing.
2021-07-28 10:03:10 +00:00
bool ok;
int fd = fdString.toInt(&ok);
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
if (ok) {
[kwin_wrapper] Transfer ownership of Xwayland socket creation and Xauthority to the wrapper This way if kwin_wayland crashes we don't need to ensure that new environment variables need to get synced across the new env. This fixes an issue where spawning an xwayland application from a wayland window that survives a crash would fail. By moving the logic here we no longer need to wait for kwin_wayland to start before starting plasmashell or even ksmserver as all environment variables are set. As long as the wrapper is ready we can continue starting and clients will just block on connect. That should still allow for both a lot of optimisations both for speed and cleaning up the startplasma-wayland scripts. This will be addressed in follow up patches. Use of kwin_wayland directly with xwayland is still supported for testing.
2021-07-28 10:03:10 +00:00
// make sure we don't leak this FD to children
fcntl(fd, F_SETFD, O_CLOEXEC);
a.addXwaylandSocketFileDescriptor(fd);
}
}
if (parser.isSet(xwaylandDisplayOption)) {
a.setXwaylandDisplay(parser.value(xwaylandDisplayOption));
} else {
std::cerr << "Using xwayland-fd without xwayland-display is undefined" << std::endl;
return 1;
}
if (parser.isSet(xwaylandXAuthorityOption)) {
a.setXwaylandXauthority(parser.value(xwaylandXAuthorityOption));
}
}
}
[wayland] Add positional arguments to be programs to starts This allows to start applications once kwin_wayland is started. E.g. kwin_wayland --libinput --xwayland --framebuffer /usr/bin/startkde Thus it would start startkde once both Wayland Server and Xwayland are up and running and ready for connection. This resolves the problem that prior to startup it is not known which will be the X11 display variable. By passing the environment to the process by KWin this problem is resolved.
2015-04-21 09:21:28 +00:00
a.setApplicationsToStart(parser.positionalArguments());
[wayland] Add a command-line option to start an input method server Input-method servers, like maliit, need to be known to KWin since KWin needs to know about virtual keyboards. Virtual keyboards should be shown as OSD layers, and they are one of the types of windows that actually should be showable when the lock screen is active. kwin_wayland --inputmethod /path/to/your/input-server tries to start the input server. The input-server's window never gets keyboard focus and is shown on top of all windows except for KWin's internal clients.
2015-06-13 02:06:12 +00:00
a.setInputMethodServerToStart(parser.value(inputMethodOption));
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
a.start();
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
return a.exec();
}
Reference in a new issue Copy permalink