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

678 lines
24 KiB
C++
Raw Normal View History

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 - the KDE window manager
This file is part of the KDE project.
Copyright (C) 2014 Martin Gräßlin <mgraesslin@kde.org>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*********************************************************************/
#include "main_wayland.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"
Integrate QtVirtualKeyboard into KWin/Wayland Summary: The idea is to have KWin provide a virtual keyboard. To support this KWin uses the QT_IM_MODULE qtvirtualkeyboard and makes sure that the QPA plugin loads it. KWin has a new class VirtualKeyboard which acts as the focus object and the "proxy" for input methods. The QPA plugin ensures that this is the focusObject, so that all input method related events are sent to this class. From there it will be possible to delegate to other applications through the Wayland interfaces. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1638
2016-04-29 13:05:03 +00:00
#include "virtualkeyboard.h"
[kwin_wayland] Support using platform wayland for the QPA This reorders the startup sequence quite a bit: 1. Create QAbstractEventDispatcher and install it on QCoreApplication 2. Create Application 3. Start Xwayland, use thread to get when its ready 4. Create xcb connection 5. perform startup For using the wayland QPA it needs a patch in QtWayland which will be part of Qt 5.4.2, otherwise it blocks.
2015-02-20 08:33:36 +00:00
#include "workspace.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
#include <config-kwin.h>
// kwin
Rename abstract_backend.(h|cpp) to platform.(h|cpp) Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1340
2016-04-07 07:24:17 +00:00
#include "platform.h"
[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
#include "effects.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"
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"
[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
#include "xwl/xwayland.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
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
// KWayland
#include <KWayland/Server/display.h>
[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
#include <KWayland/Server/seat_interface.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
#include <KLocalizedString>
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
#include <KPluginLoader>
#include <KPluginMetaData>
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
#include <KCrash>
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
#include <KQuickAddons/QtQuickSettings>
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 <qplatformdefs.h>
#include <QCommandLineParser>
[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>
Unpolish QStyle on QApp prior to destroying internal Wayland connection Summary: The QStyle might interact with our internal Wayland connection. If the cleanup happens after destroying our internal Wayland connection KWin will crash at tear-down. With this change the QStyle can perform cleanup already prior to the deconstruction of the Wayland connection. CCBUG: 372001 Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3241
2016-11-03 10:00:08 +00:00
#include <QStyle>
[kwin_wayland] Support using platform wayland for the QPA This reorders the startup sequence quite a bit: 1. Create QAbstractEventDispatcher and install it on QCoreApplication 2. Create Application 3. Start Xwayland, use thread to get when its ready 4. Create xcb connection 5. perform startup For using the wayland QPA it needs a patch in QtWayland which will be part of Qt 5.4.2, otherwise it blocks.
2015-02-20 08:33:36 +00:00
#include <QDebug>
[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>
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
// system
[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
#if HAVE_SYS_PRCTL_H
#include <sys/prctl.h>
#endif
Disallow ptrace on greeter and kwin_wayland process on FreeBSD [... for the future] Summary: Similar to[[ https://phabricator.kde.org/D1216 | D1216 ]] add procctl call to disable ptrace on FreeBSD. We cannot do the procfs-lookup to check whether the process is already being run inside gdb -- however, on FreeBSD, we could use the P_TRACED flag of the process to figure this out: > sys/proc.h:#define P_TRACED 0x00800 /* Debugged process being traced. */ And the code would look something similar to ``` pid_t pid = getpid(); struct procstat *prstat = procstat_open_sysctl(); struct kinfo_proc *procinfo; unsigned int cnt; procinfo = procstat_getprocs(prstat, KERN_PROC_PID, pid, &cnt); long p_flags = procinfo->ki_flag; int p_traced = p_flags & P_TRACED; if (p_traced != P_TRACED) { mode = PROC_TRACE_CTL_DISABLE; procctl(P_PID, getpid(), PROC_TRACE_CTL, &mode); } procstat_freeprocs(prstat,procinfo); procstat_close(prstat); ``` But as wayland is [far] in the future on FreeBSD, and that check above is a bit lengthy, I think it is enough if we add it once it is needed. Reviewers: rakuco, graesslin Reviewed By: graesslin Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1425
2016-05-10 06:49:58 +00:00
#if HAVE_SYS_PROCCTL_H
#include <sys/procctl.h>
#endif
[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
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
#if HAVE_LIBCAP
#include <sys/capability.h>
#endif
#include <sched.h>
[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
#include <iostream>
[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>
[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
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
{
[kwin-wayland] Add signal handler also to main_wayland REVIEW: 119760
2014-08-13 11:13:44 +00:00
static void sighandler(int)
{
QApplication::exit();
}
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)
Ensure libinput connection thread uses real time scheduling Summary: The SCHED_RESET_ON_FORK results in threads (not only processes) to have the scheduling policy reset to default. This means that the libinput thread is not real time, but this was actually intended. To solve this problem KWin does start without the RESET_ON_FORK flag during startup. Once createInput has been called the scheduling is adjusted again and RESET_ON_FORK is added again. This results in the libinput thread and all threads Qt starts in between (e.g. dbus) to gain real time policy. But it is still not leaked to other processes or to threads in KWin which don't need it. Other options considered: just don't use RESET_ON_FORK and instead manually reset on fork. This would mean all threads in KWin gain real time, but we don't need this. It's only interesting for the main (rendering, Wayland thread) and the input thread. Also the danger to leak into another process is too high. Keeping the capability till the libinput thread is created and adjust the thread itself. This option was discarded as I don't want KWin to have any capabilities when the QApplication is started. Test Plan: ps -eL -o class,rtprio,cmd,comm | grep kwin_wayland Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D8065
2017-09-30 07:36:30 +00:00
enum class RealTimeFlags
{
DontReset,
ResetOnFork
};
namespace {
void gainRealTime(RealTimeFlags flags = RealTimeFlags::DontReset)
{
#if HAVE_SCHED_RESET_ON_FORK
const int minPriority = sched_get_priority_min(SCHED_RR);
struct sched_param sp;
sp.sched_priority = minPriority;
int policy = SCHED_RR;
if (flags == RealTimeFlags::ResetOnFork) {
policy |= SCHED_RESET_ON_FORK;
}
sched_setscheduler(0, policy, &sp);
Fix unused param warnings Summary: Compiler: GCC 7.3.1 Distro: Arch Linux Compiler warnings: ``` /home/vlad/KDE/src/kde/workspace/kwin/effects/blur/blur.cpp: In member function ‘void KWin::BlurEffect::upscaleRenderToScreen(KWin::GLVertexBuffer*, int, int, QMatrix4x4, QRect, QPoint)’: /home/vlad/KDE/src/kde/workspace/kwin/effects/blur/blur.cpp:677:129: warning: unused parameter ‘windowShape’ [-Wunused-parameter] void BlurEffect::upscaleRenderToScreen(GLVertexBuffer *vbo, int vboStart, int blurRectCount, QMatrix4x4 screenProjection, QRect windowShape, QPoint windowPosition) ^~~~~~~~~~~ ``` ``` /home/vlad/KDE/src/kde/workspace/kwin/main_wayland.cpp: In function ‘void KWin::{anonymous}::gainRealTime(KWin::RealTimeFlags)’: /home/vlad/KDE/src/kde/workspace/kwin/main_wayland.cpp:95:56: warning: unused parameter ‘flags’ [-Wunused-parameter] void gainRealTime(RealTimeFlags flags = RealTimeFlags::DontReset) ``` Reviewers: #kwin, davidedmundson Reviewed By: davidedmundson Subscribers: anemeth, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D12208
2018-04-20 18:06:59 +00:00
#else
Q_UNUSED(flags);
Ensure libinput connection thread uses real time scheduling Summary: The SCHED_RESET_ON_FORK results in threads (not only processes) to have the scheduling policy reset to default. This means that the libinput thread is not real time, but this was actually intended. To solve this problem KWin does start without the RESET_ON_FORK flag during startup. Once createInput has been called the scheduling is adjusted again and RESET_ON_FORK is added again. This results in the libinput thread and all threads Qt starts in between (e.g. dbus) to gain real time policy. But it is still not leaked to other processes or to threads in KWin which don't need it. Other options considered: just don't use RESET_ON_FORK and instead manually reset on fork. This would mean all threads in KWin gain real time, but we don't need this. It's only interesting for the main (rendering, Wayland thread) and the input thread. Also the danger to leak into another process is too high. Keeping the capability till the libinput thread is created and adjust the thread itself. This option was discarded as I don't want KWin to have any capabilities when the QApplication is started. Test Plan: ps -eL -o class,rtprio,cmd,comm | grep kwin_wayland Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D8065
2017-09-30 07:36:30 +00:00
#endif
}
}
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)
[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
: ApplicationWaylandAbstract(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;
}
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
if (kwinApp()->platform()) {
kwinApp()->platform()->setOutputsEnabled(false);
}
[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) {
static_cast<EffectsHandlerImpl*>(effects)->unloadAllEffects();
}
[xwl] Generic X selections translation mechanism with Clipboard support Summary: In this patch an infrastructure is created to represent generic X selections in a Wayland session and use them for data transfers between Xwayland windows and Wayland native clients. The central manager is the DataBridge class, in which Selection objects can be created. This is hard-coded and such a Selection object persists until the end of the session, so no arbitrary selections can be created on the fly. For now the X Clipboard selection is supported, whose corresponding mechanism in the Wayland protocol is just called Selection. A Selection object listens for selection owner changes on the X side and for similar events into the Wayland server interfaces. If a data provider is available a selection source object is created by the Selection object. In case data is requested on the other side, a data transfer is initialized by creating a Transfer object. A Selection keeps track of all transfers and makes sure that they are destroyed when they are finished or in case they idle because of misbehaving clients. The Clipboard class translates the X Clipboard via a proxy window. Selection changes on the Wayland side are listened to through a new signal on the active KWayland seat interface. The previously used X clipboard syncer helper is disabled. The clipboard sync autotest is changed to the new mechanism. BUG: 394765 BUG: 395313 Test Plan: Manually and clipboard sync autotest. Reviewers: #kwin Subscribers: zzag, graesslin, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D15061
2018-08-21 20:06:42 +00:00
if (m_xwayland) {
// needs to be done before workspace gets destroyed
m_xwayland->prepareDestroy();
}
Destroy Workspace after unloading all effects CI system shows that on tear down an effect might call into Workspace after it's destroyed. Unloading all effects prior to deleting Workspace should(TM) fix that. Unfortunately I'm not able to reproduce the problem locally, so build.kde.org needs to verify.
2016-04-26 11:40:24 +00:00
destroyWorkspace();
waylandServer()->dispatch();
[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
Unpolish QStyle on QApp prior to destroying internal Wayland connection Summary: The QStyle might interact with our internal Wayland connection. If the cleanup happens after destroying our internal Wayland connection KWin will crash at tear-down. With this change the QStyle can perform cleanup already prior to the deconstruction of the Wayland connection. CCBUG: 372001 Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3241
2016-11-03 10:00:08 +00:00
if (QStyle *s = style()) {
s->unpolish(this);
}
[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
// kill Xwayland before terminating its connection
delete m_xwayland;
m_xwayland = nullptr;
[wayland] Destroy all ClientConnections on tear down Ensures that all Wayland objects are destroyed and the cleanup handling is performed before tearing down the Compositor. This fixes for example a crash if a Surface with a Shadow is still around at tear down.
2015-11-18 09:29:10 +00:00
waylandServer()->terminateClientConnections();
[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();
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);
}
[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();
[wayland] Set internal cursor through WaylandCursorTheme in AbstractBackend Getting the cursor image from the cursor theme is unfortunately not straight forward. We have three different libraries and all have drawbacks: * XCursor - we just kicked it out * xcb-util/cursor - only provides xcb_cursor_t, so a dependency on X * wayland-cursor - only a client side API The picked solution is using wayland-cursor. It provides the cursor in a wl_buffer. Unfortunately the client side API does not easily allow to a) read it back b) init without a wl_shm_pool Thus we need to work this around: * create an internal connection * get a ShmPool on it * init WaylandCursorTheme with this ShmPool * get the cursor wl_buffer from the theme * trigger a roundtrip * get the corresponding BufferInterface for the buffer * set the content as the software cursor
2015-04-02 12:37:23 +00:00
waylandServer()->createInternalConnection();
[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
// try creating the Wayland Backend
createInput();
Ensure libinput connection thread uses real time scheduling Summary: The SCHED_RESET_ON_FORK results in threads (not only processes) to have the scheduling policy reset to default. This means that the libinput thread is not real time, but this was actually intended. To solve this problem KWin does start without the RESET_ON_FORK flag during startup. Once createInput has been called the scheduling is adjusted again and RESET_ON_FORK is added again. This results in the libinput thread and all threads Qt starts in between (e.g. dbus) to gain real time policy. But it is still not leaked to other processes or to threads in KWin which don't need it. Other options considered: just don't use RESET_ON_FORK and instead manually reset on fork. This would mean all threads in KWin gain real time, but we don't need this. It's only interesting for the main (rendering, Wayland thread) and the input thread. Also the danger to leak into another process is too high. Keeping the capability till the libinput thread is created and adjust the thread itself. This option was discarded as I don't want KWin to have any capabilities when the QApplication is started. Test Plan: ps -eL -o class,rtprio,cmd,comm | grep kwin_wayland Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D8065
2017-09-30 07:36:30 +00:00
// now libinput thread has been created, adjust scheduler to not leak into other processes
gainRealTime(RealTimeFlags::ResetOnFork);
Integrate QtVirtualKeyboard into KWin/Wayland Summary: The idea is to have KWin provide a virtual keyboard. To support this KWin uses the QT_IM_MODULE qtvirtualkeyboard and makes sure that the QPA plugin loads it. KWin has a new class VirtualKeyboard which acts as the focus object and the "proxy" for input methods. The QPA plugin ensures that this is the focusObject, so that all input method related events are sent to this class. From there it will be possible to delegate to other applications through the Wayland interfaces. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1638
2016-04-29 13:05:03 +00:00
VirtualKeyboard::create(this);
[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
createBackend();
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
TabletModeManager::create(this);
[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
}
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
[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
void ApplicationWayland::createBackend()
{
Rename AbstractBackend to Platform
2016-04-07 07:18:10 +00:00
connect(platform(), &Platform::screensQueried, this, &ApplicationWayland::continueStartupWithScreens);
connect(platform(), &Platform::initFailed, this,
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
[] () {
std::cerr << "FATAL ERROR: backend failed to initialize, exiting now" << std::endl;
Call QCoreApplication::exit instead of stdlib exit to terminate if platform fails Summary: We need to properly tear down the application - this can be achieved through QCoreApplication::exit. Otherwise there is a chance that the cleanup handling crashes. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2136
2016-07-11 12:34:24 +00:00
QCoreApplication::exit(1);
[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
}
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
);
Rename AbstractBackend to Platform
2016-04-07 07:18:10 +00:00
platform()->init();
[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
}
[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
void ApplicationWayland::continueStartupWithScreens()
{
Rename AbstractBackend to Platform
2016-04-07 07:18:10 +00:00
disconnect(kwinApp()->platform(), &Platform::screensQueried, this, &ApplicationWayland::continueStartupWithScreens);
[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
createScreens();
[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
createCompositor();
[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
}
[wayland] Keep application startup flow inside main_wayland Summary: In a recent patch the newly added xwayland class ended up being responsible for continuing the startup, calling back into the main app to spawn the workspace. It moves the flow of startup about so it's not very readable or following class structure. This patch moves the code back into main_wayland and removes the duplication between xwayland and non-xwayland modes. There was also a misnaming of methods. Previously: continueStartupWithScreens was called after platform screens are created continueStartupWithScene was called after the scene was created continueStartupWithXwayland was called before xwayland is created This was confusing, so the names have been shuffled around to follow a consistent pattern of what has been done so far. Test Plan: Started kwin_wayland in normal and xwayland mode Ran unit tests (though some failed due to a local unrelated and as yet unindentified bug) Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19232
2019-02-23 12:17:50 +00:00
void ApplicationWayland::finalizeStartup()
Ensure Workspace is only started once in Wayland-only mode The connect to Compositor::sceneCreated must be disconnected again, otherwise a restart of the Compositor results in Workspace being created again. Thanks to our autotests for finding this problem!
2017-10-01 07:06:51 +00:00
{
[wayland] Keep application startup flow inside main_wayland Summary: In a recent patch the newly added xwayland class ended up being responsible for continuing the startup, calling back into the main app to spawn the workspace. It moves the flow of startup about so it's not very readable or following class structure. This patch moves the code back into main_wayland and removes the duplication between xwayland and non-xwayland modes. There was also a misnaming of methods. Previously: continueStartupWithScreens was called after platform screens are created continueStartupWithScene was called after the scene was created continueStartupWithXwayland was called before xwayland is created This was confusing, so the names have been shuffled around to follow a consistent pattern of what has been done so far. Test Plan: Started kwin_wayland in normal and xwayland mode Ran unit tests (though some failed due to a local unrelated and as yet unindentified bug) Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19232
2019-02-23 12:17:50 +00:00
if (m_xwayland) {
disconnect(m_xwayland, &Xwl::Xwayland::initialized, this, &ApplicationWayland::finalizeStartup);
}
Ensure Workspace is only started once in Wayland-only mode The connect to Compositor::sceneCreated must be disconnected again, otherwise a restart of the Compositor results in Workspace being created again. Thanks to our autotests for finding this problem!
2017-10-01 07:06:51 +00:00
startSession();
createWorkspace();
notifyKSplash();
}
[wayland] Keep application startup flow inside main_wayland Summary: In a recent patch the newly added xwayland class ended up being responsible for continuing the startup, calling back into the main app to spawn the workspace. It moves the flow of startup about so it's not very readable or following class structure. This patch moves the code back into main_wayland and removes the duplication between xwayland and non-xwayland modes. There was also a misnaming of methods. Previously: continueStartupWithScreens was called after platform screens are created continueStartupWithScene was called after the scene was created continueStartupWithXwayland was called before xwayland is created This was confusing, so the names have been shuffled around to follow a consistent pattern of what has been done so far. Test Plan: Started kwin_wayland in normal and xwayland mode Ran unit tests (though some failed due to a local unrelated and as yet unindentified bug) Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19232
2019-02-23 12:17:50 +00:00
void ApplicationWayland::continueStartupWithScene()
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
{
[wayland] Keep application startup flow inside main_wayland Summary: In a recent patch the newly added xwayland class ended up being responsible for continuing the startup, calling back into the main app to spawn the workspace. It moves the flow of startup about so it's not very readable or following class structure. This patch moves the code back into main_wayland and removes the duplication between xwayland and non-xwayland modes. There was also a misnaming of methods. Previously: continueStartupWithScreens was called after platform screens are created continueStartupWithScene was called after the scene was created continueStartupWithXwayland was called before xwayland is created This was confusing, so the names have been shuffled around to follow a consistent pattern of what has been done so far. Test Plan: Started kwin_wayland in normal and xwayland mode Ran unit tests (though some failed due to a local unrelated and as yet unindentified bug) Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19232
2019-02-23 12:17:50 +00:00
disconnect(Compositor::self(), &Compositor::sceneCreated, this, &ApplicationWayland::continueStartupWithScene);
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
m_xwayland = new Xwl::Xwayland(this);
connect(m_xwayland, &Xwl::Xwayland::criticalError, this, [](int code) {
// we currently exit on Xwayland errors always directly
// TODO: restart Xwayland
std::cerr << "Xwayland had a critical error. Going to exit now." << std::endl;
exit(code);
});
[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(m_xwayland, &Xwl::Xwayland::initialized, this, &ApplicationWayland::finalizeStartup);
[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
m_xwayland->init();
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()
{
[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()) {
int socket = dup(waylandServer()->createInputMethodConnection());
if (socket >= 0) {
[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
QProcessEnvironment environment = processStartupEnvironment();
[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
environment.insert(QStringLiteral("WAYLAND_SOCKET"), QByteArray::number(socket));
environment.insert(QStringLiteral("QT_QPA_PLATFORM"), QStringLiteral("wayland"));
environment.remove("DISPLAY");
environment.remove("WAYLAND_DISPLAY");
Unblock signals in child processes We need to unblock the signals blocked with pthread_sigmask. This caused kdeinit to block, because it relies on SIGUSR1. BUG: 356580 FIXED-IN: 5.5.1 REVIEW: 126361
2015-12-15 09:22:03 +00:00
QProcess *p = new Process(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);
[wayland] Destroy input method connection after process finished More cleanup.
2015-11-10 13:38:45 +00:00
auto finishedSignal = static_cast<void (QProcess::*)(int, QProcess::ExitStatus)>(&QProcess::finished);
connect(p, finishedSignal, this,
[this, p] {
if (waylandServer()) {
waylandServer()->destroyInputMethodConnection();
}
p->deleteLater();
}
);
[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
p->setProcessEnvironment(environment);
p->start(m_inputMethodServerToStart);
p->waitForStarted();
}
}
[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()) {
Unblock signals in child processes We need to unblock the signals blocked with pthread_sigmask. This caused kdeinit to block, because it relies on SIGUSR1. BUG: 356580 FIXED-IN: 5.5.1 REVIEW: 126361
2015-12-15 09:22:03 +00:00
QProcess *p = new Process(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] 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
auto finishedSignal = static_cast<void (QProcess::*)(int, QProcess::ExitStatus)>(&QProcess::finished);
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
connect(p, finishedSignal, this, [](int code, QProcess::ExitStatus status) {
if (status == QProcess::CrashExit) {
qWarning() << "Session process has crashed";
QCoreApplication::exit(-1);
return;
}
if (code) {
qWarning() << "Session process exited with code" << code;
}
QCoreApplication::exit(code);
});
[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
p->start(m_sessionArgument);
}
[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()) {
for (const QString &application: m_applicationsToStart) {
// 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
Unblock signals in child processes We need to unblock the signals blocked with pthread_sigmask. This caused kdeinit to block, because it relies on SIGUSR1. BUG: 356580 FIXED-IN: 5.5.1 REVIEW: 126361
2015-12-15 09:22:03 +00:00
QProcess *p = new Process(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] 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
p->start(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
}
[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
static const QString s_waylandPlugin = QStringLiteral("KWinWaylandWaylandBackend");
static const QString s_x11Plugin = QStringLiteral("KWinWaylandX11Backend");
static const QString s_fbdevPlugin = QStringLiteral("KWinWaylandFbdevBackend");
#if HAVE_DRM
static const QString s_drmPlugin = QStringLiteral("KWinWaylandDrmBackend");
#endif
#if HAVE_LIBHYBRIS
static const QString s_hwcomposerPlugin = QStringLiteral("KWinWaylandHwcomposerBackend");
#endif
[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
static const QString s_virtualPlugin = QStringLiteral("KWinWaylandVirtualBackend");
[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
static QString automaticBackendSelection()
{
if (qEnvironmentVariableIsSet("WAYLAND_DISPLAY")) {
return s_waylandPlugin;
}
if (qEnvironmentVariableIsSet("DISPLAY")) {
return s_x11Plugin;
}
#if HAVE_LIBHYBRIS
if (qEnvironmentVariableIsSet("ANDROID_ROOT")) {
return s_hwcomposerPlugin;
}
#endif
#if HAVE_DRM
return s_drmPlugin;
#endif
return s_fbdevPlugin;
}
[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
static void disablePtrace()
{
#if HAVE_PR_SET_DUMPABLE
// check whether we are running under a debugger
const QFileInfo parent(QStringLiteral("/proc/%1/exe").arg(getppid()));
Make kwin_wayland remotely debuggable Differential Revision: https://phabricator.kde.org/D6160
2017-06-11 19:16:56 +00:00
if (parent.isSymLink() &&
(parent.symLinkTarget().endsWith(QLatin1String("/gdb")) ||
parent.symLinkTarget().endsWith(QLatin1String("/gdbserver")))) {
[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
// debugger, don't adjust
return;
}
// disable ptrace in kwin_wayland
prctl(PR_SET_DUMPABLE, 0);
#endif
Disallow ptrace on greeter and kwin_wayland process on FreeBSD [... for the future] Summary: Similar to[[ https://phabricator.kde.org/D1216 | D1216 ]] add procctl call to disable ptrace on FreeBSD. We cannot do the procfs-lookup to check whether the process is already being run inside gdb -- however, on FreeBSD, we could use the P_TRACED flag of the process to figure this out: > sys/proc.h:#define P_TRACED 0x00800 /* Debugged process being traced. */ And the code would look something similar to ``` pid_t pid = getpid(); struct procstat *prstat = procstat_open_sysctl(); struct kinfo_proc *procinfo; unsigned int cnt; procinfo = procstat_getprocs(prstat, KERN_PROC_PID, pid, &cnt); long p_flags = procinfo->ki_flag; int p_traced = p_flags & P_TRACED; if (p_traced != P_TRACED) { mode = PROC_TRACE_CTL_DISABLE; procctl(P_PID, getpid(), PROC_TRACE_CTL, &mode); } procstat_freeprocs(prstat,procinfo); procstat_close(prstat); ``` But as wayland is [far] in the future on FreeBSD, and that check above is a bit lengthy, I think it is enough if we add it once it is needed. Reviewers: rakuco, graesslin Reviewed By: graesslin Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1425
2016-05-10 06:49:58 +00:00
#if HAVE_PROC_TRACE_CTL
// FreeBSD's rudimentary procfs does not support /proc/<pid>/exe
// We could use the P_TRACED flag of the process to find out
// if the process is being debugged ond FreeBSD.
int mode = PROC_TRACE_CTL_DISABLE;
procctl(P_PID, getpid(), PROC_TRACE_CTL, &mode);
#endif
[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
}
Install a signal handler for SIGABRT and SIGSEGV for kwin_wayland Summary: kwin_wayland disables ptrace on itself. This has the side effect of core dumps no longer be created - which we want as DrKonqi doesn't work for kwin_wayland. This change introduces a dedicated signal handler for abort and segfault. The signal handler enables ptrace again, unsets itself as signal handler and raises the signal again, so that the proper crash, abort handling can be performed. Test Plan: Added a crash, added an abort and verified that coredumpctl shows the expected coredump. Reviewers: #plasma_on_wayland, #kwin, bshah Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2003
2016-06-25 12:47:41 +00:00
static void unsetDumpable(int sig)
{
#if HAVE_PR_SET_DUMPABLE
prctl(PR_SET_DUMPABLE, 1);
#endif
signal(sig, SIG_IGN);
raise(sig);
return;
}
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
void dropNiceCapability()
{
#if HAVE_LIBCAP
cap_t caps = cap_get_proc();
if (!caps) {
return;
}
cap_value_t capList[] = { CAP_SYS_NICE };
if (cap_set_flag(caps, CAP_PERMITTED, 1, capList, CAP_CLEAR) == -1) {
cap_free(caps);
return;
}
if (cap_set_flag(caps, CAP_EFFECTIVE, 1, capList, CAP_CLEAR) == -1) {
cap_free(caps);
return;
}
cap_set_proc(caps);
cap_free(caps);
#endif
}
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
[wayland] kwin_wayland is no longer a kdeinit_executable kdeinit_executable doesn't make sense in the case of kwin_wayland as start_kdeinit_wrapper will be executed after kwin_wayland thus the framework doesn't work.
2015-07-06 07:57:30 +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
{
Disallow running KWin/Wayland as root Summary: KWin is not designed to run as root. It is not hardened enough and there is a great risk that applications could attack KWin through X11 properties, Wayland protocol requests, etc. to trigger stack or heap overflows and execute random code. As clients connected to KWin could be remote there is a great risk in running KWin as root. Also clients on the same system but started as a different user could try to gain more privs by exploiting KWin. Furthermore KWin is designed to not run as root. It interacts with logind to get the devices opened which would require root. Whether KWin would work as root at all is questionable. We cannot guarantee that running KWin as root is secure, thus this change disallows running KWin and thus a Wayland session as root. Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13008
2018-05-20 19:45:51 +00:00
if (getuid() == 0) {
std::cerr << "kwin_wayland does not support running as root." << std::endl;
return 1;
}
[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
KWin::disablePtrace();
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();
KWin::dropNiceCapability();
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-wayland] Add signal handler also to main_wayland REVIEW: 119760
2014-08-13 11:13:44 +00:00
if (signal(SIGTERM, KWin::sighandler) == SIG_IGN)
signal(SIGTERM, SIG_IGN);
if (signal(SIGINT, KWin::sighandler) == SIG_IGN)
signal(SIGINT, SIG_IGN);
if (signal(SIGHUP, KWin::sighandler) == SIG_IGN)
signal(SIGHUP, SIG_IGN);
Install a signal handler for SIGABRT and SIGSEGV for kwin_wayland Summary: kwin_wayland disables ptrace on itself. This has the side effect of core dumps no longer be created - which we want as DrKonqi doesn't work for kwin_wayland. This change introduces a dedicated signal handler for abort and segfault. The signal handler enables ptrace again, unsets itself as signal handler and raises the signal again, so that the proper crash, abort handling can be performed. Test Plan: Added a crash, added an abort and verified that coredumpctl shows the expected coredump. Reviewers: #plasma_on_wayland, #kwin, bshah Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2003
2016-06-25 12:47:41 +00:00
signal(SIGABRT, KWin::unsetDumpable);
signal(SIGSEGV, KWin::unsetDumpable);
[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);
[wayland] Add initial support for taking over VirtualTerminals A new Singleton VirtualTerminal is added. It interacts with Logind to get the VTNr to take over. To get the signal to release and acquire the VT we use a signalfd with a QSocketNotifier to monitor for signals. The used signals must be blocked for all threads prior to startup otherwise they are delivered to secondary threads causing issues.
2015-03-31 07:30:19 +00:00
// ensure that no thread takes SIGUSR
Maintenance - fixing naming typos Fix typos in signal naming var Fix typo in KWin QPA environment variable
2016-01-30 11:31:19 +00:00
sigset_t userSignals;
sigemptyset(&userSignals);
sigaddset(&userSignals, SIGUSR1);
sigaddset(&userSignals, SIGUSR2);
pthread_sigmask(SIG_BLOCK, &userSignals, nullptr);
[kwin-wayland] Add signal handler also to main_wayland REVIEW: 119760
2014-08-13 11:13:44 +00:00
[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");
Integrate QtVirtualKeyboard into KWin/Wayland Summary: The idea is to have KWin provide a virtual keyboard. To support this KWin uses the QT_IM_MODULE qtvirtualkeyboard and makes sure that the QPA plugin loads it. KWin has a new class VirtualKeyboard which acts as the focus object and the "proxy" for input methods. The QPA plugin ensures that this is the focusObject, so that all input method related events are sent to this class. From there it will be possible to delegate to other applications through the Wayland interfaces. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1638
2016-04-29 13:05:03 +00:00
qputenv("QT_IM_MODULE", "qtvirtualkeyboard");
[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();
[wayland] Reset QT_QPA_PLATFORM to wayland after starting Application We only need to force QT_QPA_PLATFORM to be our own plugin when starting the application. As KWin starts other processes (e.g. kcmshell5) we need to ensure that the env variable has a sane value. No other process can load our QPA plugin after all. Reviewed-By: Bhushan Shah
2015-11-03 15:52:55 +00:00
// reset QT_QPA_PLATFORM to a sane value for any processes started from KWin
setenv("QT_QPA_PLATFORM", "wayland", true);
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
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();
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
KQuickAddons::QtQuickSettings::init();
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
[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
const auto availablePlugins = KPluginLoader::findPlugins(QStringLiteral("org.kde.kwin.waylandbackends"));
[wayland] Add options depending on available backend plugins As distributions do not ship all plugins let's try to filter the options based on the plugins which are actually available. There is no point in allowing e.g. framebuffer just to notice then that the plugin is not shipped ending in confusing error for the user. So let's only add the options which actually make sense.
2015-10-02 07:47:27 +00:00
auto hasPlugin = [&availablePlugins] (const QString &name) {
return std::any_of(availablePlugins.begin(), availablePlugins.end(),
[name] (const KPluginMetaData &plugin) {
return plugin.pluginId() == name;
}
);
};
[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
const bool hasSizeOption = hasPlugin(KWin::s_x11Plugin) || hasPlugin(KWin::s_virtualPlugin);
[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
const bool hasOutputCountOption = hasPlugin(KWin::s_x11Plugin);
[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
const bool hasX11Option = hasPlugin(KWin::s_x11Plugin);
const bool hasVirtualOption = hasPlugin(KWin::s_virtualPlugin);
const bool hasWaylandOption = hasPlugin(KWin::s_waylandPlugin);
const bool hasFramebufferOption = hasPlugin(KWin::s_fbdevPlugin);
#if HAVE_DRM
const bool hasDrmOption = hasPlugin(KWin::s_drmPlugin);
#endif
#if HAVE_LIBHYBRIS
const bool hasHwcomposerOption = hasPlugin(KWin::s_hwcomposerPlugin);
#endif
[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
[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 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
QCommandLineOption framebufferOption(QStringLiteral("framebuffer"),
i18n("Render to framebuffer."));
QCommandLineOption framebufferDeviceOption(QStringLiteral("fb-device"),
i18n("The framebuffer device to render to."),
QStringLiteral("fbdev"));
[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"),
i18n("The scale for windowed mode. Default value is 1."),
QStringLiteral("scale"));
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"),
i18n("The number of windows to open as outputs in windowed mode. Default value is 1"),
Fix wrong command line argument name Reviewed by David Edmundson
2019-03-20 14:12:45 +00:00
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
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);
[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
if (hasX11Option) {
[wayland] Add options depending on available backend plugins As distributions do not ship all plugins let's try to filter the options based on the plugins which are actually available. There is no point in allowing e.g. framebuffer just to notice then that the plugin is not shipped ending in confusing error for the user. So let's only add the options which actually make sense.
2015-10-02 07:47:27 +00:00
parser.addOption(x11DisplayOption);
}
[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
if (hasWaylandOption) {
[wayland] Add options depending on available backend plugins As distributions do not ship all plugins let's try to filter the options based on the plugins which are actually available. There is no point in allowing e.g. framebuffer just to notice then that the plugin is not shipped ending in confusing error for the user. So let's only add the options which actually make sense.
2015-10-02 07:47:27 +00:00
parser.addOption(waylandDisplayOption);
}
[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
if (hasFramebufferOption) {
[wayland] Add options depending on available backend plugins As distributions do not ship all plugins let's try to filter the options based on the plugins which are actually available. There is no point in allowing e.g. framebuffer just to notice then that the plugin is not shipped ending in confusing error for the user. So let's only add the options which actually make sense.
2015-10-02 07:47:27 +00:00
parser.addOption(framebufferOption);
parser.addOption(framebufferDeviceOption);
}
[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
if (hasVirtualOption) {
[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
parser.addOption(virtualFbOption);
}
[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
if (hasSizeOption) {
[wayland] Add options depending on available backend plugins As distributions do not ship all plugins let's try to filter the options based on the plugins which are actually available. There is no point in allowing e.g. framebuffer just to notice then that the plugin is not shipped ending in confusing error for the user. So let's only add the options which actually make sense.
2015-10-02 07:47:27 +00:00
parser.addOption(widthOption);
parser.addOption(heightOption);
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
parser.addOption(scaleOption);
[wayland] Add options depending on available backend plugins As distributions do not ship all plugins let's try to filter the options based on the plugins which are actually available. There is no point in allowing e.g. framebuffer just to notice then that the plugin is not shipped ending in confusing error for the user. So let's only add the options which actually make sense.
2015-10-02 07:47:27 +00:00
}
[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
if (hasOutputCountOption) {
parser.addOption(outputCountOption);
}
Add a hwcomposer backend based on libhybris This backend interacts with libhybris to create a hwcomposer which is used for creating the egl context and surface. The initial version of this backend is based on test_hwcomposer.cpp provided by libhybris. Please note that using the hwcomposer backend requires a newer libepoxy, the latest stable release is not able to bring up OpenGLES, so one needs a master build of libepoxy. Notes on licensing: libhybris is Apache 2.0 licensed, which is not compatile with GPLv2. But it is compatible with GPLv3. Thus the source files in the hwcomposer backend are licensed GPLv3+ and not GPLv2+ as the rest of KWin. If one uses KWin without the hwcomposer backend (which is obviously the default) the licence doesn't change. But if the hwcomposer backend is used the overall license of KWin changes to GPLv3+.
2015-05-06 15:47:07 +00:00
#if HAVE_LIBHYBRIS
QCommandLineOption hwcomposerOption(QStringLiteral("hwcomposer"), i18n("Use libhybris hwcomposer"));
[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
if (hasHwcomposerOption) {
[wayland] Add options depending on available backend plugins As distributions do not ship all plugins let's try to filter the options based on the plugins which are actually available. There is no point in allowing e.g. framebuffer just to notice then that the plugin is not shipped ending in confusing error for the user. So let's only add the options which actually make sense.
2015-10-02 07:47:27 +00:00
parser.addOption(hwcomposerOption);
}
Add a hwcomposer backend based on libhybris This backend interacts with libhybris to create a hwcomposer which is used for creating the egl context and surface. The initial version of this backend is based on test_hwcomposer.cpp provided by libhybris. Please note that using the hwcomposer backend requires a newer libepoxy, the latest stable release is not able to bring up OpenGLES, so one needs a master build of libepoxy. Notes on licensing: libhybris is Apache 2.0 licensed, which is not compatile with GPLv2. But it is compatible with GPLv3. Thus the source files in the hwcomposer backend are licensed GPLv3+ and not GPLv2+ as the rest of KWin. If one uses KWin without the hwcomposer backend (which is obviously the default) the licence doesn't change. But if the hwcomposer backend is used the overall license of KWin changes to GPLv3+.
2015-05-06 15:47:07 +00:00
#endif
Add command line option to enable libinput support kwin_wayland gains a new command line option to enable libinput support. This is needed as logind blanks the VT when the session controller releases the control. So a nested compositor can seriously affect the primary session. Thus it needs a dedicated command line switch to enable it. By default libinput support is disabled for kwin_x11 and can be enabled for kwin_wayland in case KWin is compiled with libinput support.
2014-08-15 12:03:52 +00:00
QCommandLineOption libinputOption(QStringLiteral("libinput"),
i18n("Enable libinput support for input events processing. Note: never use in a nested session."));
parser.addOption(libinputOption);
[wayland] Add a basic drm/kms backend Introduces a new (optional) dependency: libdrm. The DrmBackend currently supports finding the first connected output. It can create shared memory buffers which are used by SceneQPainter to do double buffered rendering. There is still lots to do, the following things are not yet working: * multiple outputs * page flip * OpenGL (through gbm) * restoring mode setting to start value
2015-04-09 12:49:32 +00:00
#if HAVE_DRM
QCommandLineOption drmOption(QStringLiteral("drm"), i18n("Render through drm node."));
[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
if (hasDrmOption) {
[wayland] Add options depending on available backend plugins As distributions do not ship all plugins let's try to filter the options based on the plugins which are actually available. There is no point in allowing e.g. framebuffer just to notice then that the plugin is not shipped ending in confusing error for the user. So let's only add the options which actually make sense.
2015-10-02 07:47:27 +00:00
parser.addOption(drmOption);
}
Add command line option to enable libinput support kwin_wayland gains a new command line option to enable libinput support. This is needed as logind blanks the VT when the session controller releases the control. So a nested compositor can seriously affect the primary session. Thus it needs a dedicated command line switch to enable it. By default libinput support is disabled for kwin_x11 and can be enabled for kwin_wayland in case KWin is compiled with libinput support.
2014-08-15 12:03:52 +00:00
#endif
[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);
[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
QCommandLineOption listBackendsOption(QStringLiteral("list-backends"),
i18n("List all available backends and quit."));
parser.addOption(listBackendsOption);
[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);
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
[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);
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
#ifdef KWIN_BUILD_ACTIVITIES
Disable KActivities integration on Wayland Once again KActivities causes a delay in the startup of KWin. This is not the first time it happens, that has been a problem since the start of the Wayland project. In the past we added a compile time switch due to that and added a runtime switch once it stoped freezing (20a9a2a247). And now it broke again, so let's disable again. KActivities doesn't make sense on Wayland anyway as there is no activity support for Wayland windows. Once KActivities is able to be used without freezing KWin on startup and being able to ensure that it won't break again we can reenable. But I expect guarantees about that. This must be ensured by proper autotest support to verify that in future usage of KActivities in the display manager doesn't freeze it. This is maintainer decision, due to that no pre-commit review. CCMAIL: plasma-devel@kde.org BUG: 388628
2018-01-13 15:45:42 +00:00
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
[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
if (parser.isSet(listBackendsOption)) {
for (const auto &plugin: availablePlugins) {
std::cout << std::setw(40) << std::left << qPrintable(plugin.name()) << qPrintable(plugin.description()) << std::endl;
}
return 0;
}
[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));
}
Add command line option to enable libinput support kwin_wayland gains a new command line option to enable libinput support. This is needed as logind blanks the VT when the session controller releases the control. So a nested compositor can seriously affect the primary session. Thus it needs a dedicated command line switch to enable it. By default libinput support is disabled for kwin_x11 and can be enabled for kwin_wayland in case KWin is compiled with libinput support.
2014-08-15 12:03:52 +00:00
KWin::Application::setUseLibinput(parser.isSet(libinputOption));
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;
QByteArray deviceIdentifier;
[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
[wayland] Add a basic drm/kms backend Introduces a new (optional) dependency: libdrm. The DrmBackend currently supports finding the first connected output. It can create shared memory buffers which are used by SceneQPainter to do double buffered rendering. There is still lots to do, the following things are not yet working: * multiple outputs * page flip * OpenGL (through gbm) * restoring mode setting to start value
2015-04-09 12:49:32 +00:00
#if HAVE_DRM
[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
if (hasDrmOption && parser.isSet(drmOption)) {
[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
pluginName = KWin::s_drmPlugin;
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 basic drm/kms backend Introduces a new (optional) dependency: libdrm. The DrmBackend currently supports finding the first connected output. It can create shared memory buffers which are used by SceneQPainter to do double buffered rendering. There is still lots to do, the following things are not yet working: * multiple outputs * page flip * OpenGL (through gbm) * restoring mode setting to start value
2015-04-09 12:49:32 +00:00
#endif
[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] 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
if (hasSizeOption) {
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;
}
const int height = parser.value(heightOption).toInt(&ok);
if (!ok) {
std::cerr << "FATAL ERROR incorrect value for height" << std::endl;
return 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
const qreal scale = parser.value(scaleOption).toDouble(&ok);
if (!ok || scale < 1) {
std::cerr << "FATAL ERROR incorrect value for scale" << std::endl;
return 1;
}
outputScale = scale;
[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
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
}
[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
if (hasOutputCountOption) {
bool ok = false;
const int count = parser.value(outputCountOption).toInt(&ok);
if (ok) {
outputCount = qMax(1, count);
}
}
Remove duplicated auto backend resolution Summary: kwin_wayland now automatically chooses an appropriate backend, such as DRM, nested wayland or nested X. If nested it will automatically go into windowed mode regardless of whether --windowed is set and works fine. Backend choosing logic existed duplicated in older code for kwin_wayland --windowed, with the subtle unexpected difference that it preferred running as an X client over running as a wayland cient if both are present. This simplifies codes and syncs automatic resolution behaviour. kwin_wayland --windowed with --x11-display or --wayland-display will remain the same. Test Plan: Ran kwin_wayland with and without --windowed inside another wayland. Got the same backend chosen Tested that kwin_wayland (without --windowed) on an X machine worked just fine. Reviewers: #kwin, mart Reviewed By: #kwin, mart Subscribers: mart, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13658
2018-09-13 09:20:57 +00:00
if (hasX11Option && parser.isSet(x11DisplayOption)) {
deviceIdentifier = parser.value(x11DisplayOption).toUtf8();
pluginName = KWin::s_x11Plugin;
} else if (hasWaylandOption && parser.isSet(waylandDisplayOption)) {
deviceIdentifier = parser.value(waylandDisplayOption).toUtf8();
pluginName = KWin::s_waylandPlugin;
[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
}
Remove duplicated auto backend resolution Summary: kwin_wayland now automatically chooses an appropriate backend, such as DRM, nested wayland or nested X. If nested it will automatically go into windowed mode regardless of whether --windowed is set and works fine. Backend choosing logic existed duplicated in older code for kwin_wayland --windowed, with the subtle unexpected difference that it preferred running as an X client over running as a wayland cient if both are present. This simplifies codes and syncs automatic resolution behaviour. kwin_wayland --windowed with --x11-display or --wayland-display will remain the same. Test Plan: Ran kwin_wayland with and without --windowed inside another wayland. Got the same backend chosen Tested that kwin_wayland (without --windowed) on an X machine worked just fine. Reviewers: #kwin, mart Reviewed By: #kwin, mart Subscribers: mart, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D13658
2018-09-13 09:20:57 +00:00
[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
if (hasFramebufferOption && parser.isSet(framebufferOption)) {
[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
pluginName = KWin::s_fbdevPlugin;
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
deviceIdentifier = parser.value(framebufferDeviceOption).toUtf8();
}
Add a hwcomposer backend based on libhybris This backend interacts with libhybris to create a hwcomposer which is used for creating the egl context and surface. The initial version of this backend is based on test_hwcomposer.cpp provided by libhybris. Please note that using the hwcomposer backend requires a newer libepoxy, the latest stable release is not able to bring up OpenGLES, so one needs a master build of libepoxy. Notes on licensing: libhybris is Apache 2.0 licensed, which is not compatile with GPLv2. But it is compatible with GPLv3. Thus the source files in the hwcomposer backend are licensed GPLv3+ and not GPLv2+ as the rest of KWin. If one uses KWin without the hwcomposer backend (which is obviously the default) the licence doesn't change. But if the hwcomposer backend is used the overall license of KWin changes to GPLv3+.
2015-05-06 15:47:07 +00:00
#if HAVE_LIBHYBRIS
[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
if (hasHwcomposerOption && parser.isSet(hwcomposerOption)) {
[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
pluginName = KWin::s_hwcomposerPlugin;
Add a hwcomposer backend based on libhybris This backend interacts with libhybris to create a hwcomposer which is used for creating the egl context and surface. The initial version of this backend is based on test_hwcomposer.cpp provided by libhybris. Please note that using the hwcomposer backend requires a newer libepoxy, the latest stable release is not able to bring up OpenGLES, so one needs a master build of libepoxy. Notes on licensing: libhybris is Apache 2.0 licensed, which is not compatile with GPLv2. But it is compatible with GPLv3. Thus the source files in the hwcomposer backend are licensed GPLv3+ and not GPLv2+ as the rest of KWin. If one uses KWin without the hwcomposer backend (which is obviously the default) the licence doesn't change. But if the hwcomposer backend is used the overall license of KWin changes to GPLv3+.
2015-05-06 15:47:07 +00:00
}
#endif
[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
if (hasVirtualOption && parser.isSet(virtualFbOption)) {
[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
pluginName = KWin::s_virtualPlugin;
}
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] 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
if (pluginName.isEmpty()) {
std::cerr << "No backend specified through command line argument, trying auto resolution" << std::endl;
pluginName = KWin::automaticBackendSelection();
}
[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
auto pluginIt = std::find_if(availablePlugins.begin(), availablePlugins.end(),
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
[&pluginName] (const KPluginMetaData &plugin) {
return plugin.pluginId() == pluginName;
}
);
[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
if (pluginIt == availablePlugins.end()) {
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
std::cerr << "FATAL ERROR: could not find a backend" << 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
// 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
KWin::WaylandServer::InitalizationFlags flags;
if (parser.isSet(screenLockerOption)) {
flags = KWin::WaylandServer::InitalizationFlag::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)) {
flags = KWin::WaylandServer::InitalizationFlag::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
}
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)) {
flags |= KWin::WaylandServer::InitalizationFlag::NoGlobalShortcuts;
}
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
if (!server->init(parser.value(waylandSocketOption).toUtf8(), flags)) {
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
Provide the platform() -> AbstractBackend* in KWin::Application Summary: This is the first change in a refactoring series. The aim is to: * rename AbstractBackend to Platform * move backends/ to plugins/platforms/ * don't bind platforms to Wayland only * provide a platform plugin for "normal" X11 * share more code between X11 and Wayland This change moves the platform/backend from waylandServer to Application. The init of the plugin happens directly in the Application from the KPluginMetaData. There is no need to externally init it and set the parent. WaylandServer::backend() currently just delegates to kwinApp()->platform(), the idea is to drop this method completely. The test infrastructure is also adjusted to this change. Test Plan: kwin_wayland still works, all tests pass Reviewers: #plasma, sebas Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1331
2016-04-06 15:30:00 +00:00
a.initPlatform(*pluginIt);
if (!a.platform()) {
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
std::cerr << "FATAL ERROR: could not instantiate a backend" << std::endl;
return 1;
}
if (!deviceIdentifier.isEmpty()) {
waylandServer()->backend() replaced by kwinApp()->platform()
2016-04-07 06:28:35 +00:00
a.platform()->setDeviceIdentifier(deviceIdentifier);
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
}
if (initialWindowSize.isValid()) {
waylandServer()->backend() replaced by kwinApp()->platform()
2016-04-07 06:28:35 +00:00
a.platform()->setInitialWindowSize(initialWindowSize);
[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
}
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
a.platform()->setInitialOutputScale(outputScale);
waylandServer()->backend() replaced by kwinApp()->platform()
2016-04-07 06:28:35 +00:00
a.platform()->setInitialOutputCount(outputCount);
[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);
[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
environment.insert(QStringLiteral("WAYLAND_DISPLAY"), server->display()->socketName());
a.setProcessStartupEnvironment(environment);
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
a.setStartXwayland(parser.isSet(xwaylandOption));
[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