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

735 lines
27 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"
[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
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 "abstract_backend.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"
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"
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 "xcbutils.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
// 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>
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>
[wayland] Create event dispatcher in QPA plugin We no longer need to have the event dispatcher created before starting the QApplication, thus we can leave it to the QPA plugin to creat it. Also we don't need to implement our own dispatcher any more but can use one from Qt5PlatformSupport as we link it anyways. The special need for dispatching the WaylandServer is no longer needed as we can explicitly dispatch it from the QPA plugin if needed.
2015-08-20 12:31:13 +00:00
#include <QAbstractEventDispatcher>
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 <QCommandLineParser>
[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 <QtConcurrentRun>
[kwin_wayland] Cleanup wayland_backend.[h|cpp] Remove no longer needed includes, turn one time slot methods into lambdas, etc.
2014-08-21 09:30:56 +00:00
#include <QFile>
[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>
[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 <QFutureWatcher>
[wayland] Add positional arguments to be programs to starts This allows to start applications once kwin_wayland is started. E.g. kwin_wayland --libinput --xwayland --framebuffer /usr/bin/startkde Thus it would start startkde once both Wayland Server and Xwayland are up and running and ready for connection. This resolves the problem that prior to startup it is not known which will be the X11 display variable. By passing the environment to the process by KWin this problem is resolved.
2015-04-21 09:21:28 +00:00
#include <QProcess>
[kwin_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 <QSocketNotifier>
#include <QThread>
#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
#ifdef HAVE_UNISTD_H
#include <unistd.h>
#endif // HAVE_UNISTD_H
[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
[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();
}
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
static void readDisplay(int pipe);
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)
: Application(OperationModeWaylandAndX11, argc, argv)
{
}
ApplicationWayland::~ApplicationWayland()
{
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;
}
[wayland] Disable Compositor during tear-down Prevents rendering an incomplete state and as well prevents from running performCompositing() which could access Workspace and crash.
2015-11-12 14:12:01 +00:00
waylandServer()->backend()->setOutputsEnabled(false);
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
destroyWorkspace();
[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
waylandServer()->dispatch();
[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();
}
[wayland] Don't exit due to Xwayland exiting on tear down Our Xwayland exit error handler should not run during tearing down Xwayland. Yes we expect Xwayland to exit as a response to KWin telling it to exit.
2015-11-12 13:05:09 +00:00
disconnect(m_xwaylandFailConnection);
[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
if (x11Connection()) {
Xcb::setInputFocus(XCB_INPUT_FOCUS_POINTER_ROOT);
[wayland] Ensure KWin::atoms are destroyed before doing xcb_disconnect Destroying the Atoms might call into xcb as a request might have to be discarded. If atoms are destroyed after disconnecting xcb, this'll crash.
2015-05-26 12:26:56 +00:00
destroyAtoms();
[wayland] Emit signal before x11 connection gets destroyed Used in Compositor to destroy the cm_selection. This would crash otherwise as it calls into xcb after Xwayland is destroyed.
2015-11-12 14:13:42 +00:00
emit x11ConnectionAboutToBeDestroyed();
[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
xcb_disconnect(x11Connection());
[wayland] Ensure to not call into x11 on Compositor tear-down During Compositor tear down Xwayland is already destroyed. Thus it doesn't make sense to try to delete the support properties: either it freezes in xcb or it crashes because the connection is null. At the same time we also ensure that the connection internally is reset to null. Note: the one in kwinglobals.h caches and could cause use-after-free errors. Any tear-down code must be migrated to kwinApp()->x11Connection().
2015-11-10 12:54:26 +00:00
setX11Connection(nullptr);
[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
}
[wayland] Use QProcess to start XWayland server The code didn't use QProcess as in the early days of main_wayland.cpp Xwayland had to be started before the QGuiApplication was constructed. As this requirement doesn't exist any more we can use QProcess and improve the interaction by e.g. provide useful error messages if Xwayland couldn't be started.
2015-05-21 13:11:11 +00:00
if (m_xwaylandProcess) {
m_xwaylandProcess->terminate();
[wayland] Don't use waitForFinished on the Xwayland QProcess WaitForFinished blocks our main thread, but Xwayland wants to talk to Wayland and blocks as well. So let's ensure events are processed while terminating Xwayland.
2015-11-12 14:15:44 +00:00
while (m_xwaylandProcess->state() != QProcess::NotRunning) {
processEvents(QEventLoop::WaitForMoreEvents);
}
[wayland] Destroy Xwayland's ClientConnection on tear down We need to destroy the ClientConnections we create. Also we need to disconnect our Xwayland error handling before destroying it, otherwise it would trigger the abort for crashing Xwayland.
2015-11-10 13:21:48 +00:00
waylandServer()->destroyXWaylandConnection();
[wayland] Use QProcess to start XWayland server The code didn't use QProcess as in the early days of main_wayland.cpp Xwayland had to be started before the QGuiApplication was constructed. As this requirement doesn't exist any more we can use QProcess and improve the interaction by e.g. provide useful error messages if Xwayland couldn't be started.
2015-05-21 13:11:11 +00:00
}
[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()
{
[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
setOperationMode(m_startXWayland ? OperationModeXwayland : OperationModeWaylandAndX11);
[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();
[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();
[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
Remove crash handling in kwin_wayland This patch introduces additional method to Application class that has default policy of restarting the app. This method is overridden for wayland case disabling this step. REVIEW: 126655
2016-01-30 11:31:28 +00:00
void ApplicationWayland::setupCrashHandler()
{
// this disables auto-restart of kwin_wayland
// do nothing hence allowing OS to create dump and so on
}
[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()
{
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
AbstractBackend *backend = waylandServer()->backend();
connect(backend, &AbstractBackend::screensQueried, this, &ApplicationWayland::continueStartupWithScreens);
connect(backend, &AbstractBackend::initFailed, this,
[] () {
std::cerr << "FATAL ERROR: backend failed to initialize, exiting now" << std::endl;
::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
);
backend->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()
{
[wayland] AbstractBackend provides signal screensQueried With this change all backends need to emit the screensQueried signal at some point. So far only x11 backend did not provide the signal, wayland had a comparable delayed init mechanism. Now all backends use the same mechanism.
2015-05-06 07:03:54 +00:00
disconnect(waylandServer()->backend(), &AbstractBackend::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();
waylandServer()->initOutputs();
if (!m_startXWayland) {
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
continueStartupWithX();
[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
return;
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
}
[wayland] Start Compositor and Scene before Workspace For Xwayland we need to have the Scene (and EglDisplay) created prior to starting Xwayland and having X11. This requires creating the Compositor before creating Workspace and starting Xwayland. To support this the startup of Compositor is split into two parts: prior and after Workspace creation. The change might also be interesting for the kwin_x11 case as it could result in the compositor being up in a quicker way.
2015-02-23 14:57:00 +00:00
createCompositor();
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
connect(Compositor::self(), &Compositor::sceneCreated, this, &ApplicationWayland::startXwaylandServer);
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
}
void ApplicationWayland::continueStartupWithX()
{
createX11Connection();
[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
xcb_connection_t *c = x11Connection();
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
if (!c) {
// about to quit
return;
}
[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
QSocketNotifier *notifier = new QSocketNotifier(xcb_get_file_descriptor(c), QSocketNotifier::Read, this);
auto processXcbEvents = [this, c] {
while (auto event = xcb_poll_for_event(c)) {
updateX11Time(event);
[wayland] Pass X11 events through the native event filters E.g. KSelectionOwner installs a native event filter and listens for xcb events. Without that the KSelectionOwner::claim never succeeds and for other X11 applications it will look like Compositing is not supported.
2015-04-22 09:23:06 +00:00
long result = 0;
if (QThread::currentThread()->eventDispatcher()->filterNativeEvent(QByteArrayLiteral("xcb_generic_event_t"), event, &result)) {
free(event);
continue;
}
[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
if (Workspace::self()) {
Workspace::self()->workspaceEvent(event);
}
free(event);
}
xcb_flush(c);
};
connect(notifier, &QSocketNotifier::activated, this, processXcbEvents);
connect(QThread::currentThread()->eventDispatcher(), &QAbstractEventDispatcher::aboutToBlock, this, processXcbEvents);
connect(QThread::currentThread()->eventDispatcher(), &QAbstractEventDispatcher::awake, this, processXcbEvents);
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] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
// create selection owner for WM_S0 - magic X display number expected by XWayland
KSelectionOwner owner("WM_S0", c, x11RootWindow());
owner.claim(true);
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
createAtoms();
setupEventFilters();
// Check whether another windowmanager is running
const uint32_t maskValues[] = {XCB_EVENT_MASK_SUBSTRUCTURE_REDIRECT};
ScopedCPointer<xcb_generic_error_t> redirectCheck(xcb_request_check(connection(),
xcb_change_window_attributes_checked(connection(),
rootWindow(),
XCB_CW_EVENT_MASK,
maskValues)));
if (!redirectCheck.isNull()) {
Move creating WaylandBackend into ApplicationWayland Early creation to ensure that we can abort if there is no Wayland display to connect to.
2014-08-12 07:45:43 +00:00
fputs(i18n("kwin_wayland: an X11 window manager is running on the X11 Display.\n").toLocal8Bit().constData(), stderr);
::exit(1);
}
[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) {
[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 = m_environment;
[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();
}
}
Port away from KToolInvocation The problem with KToolInvocation is that it creates a dead lock on Wayland in case kdeinit is not already running. It starts kdeinit and does a QProcess::waitForFinished and our kdeinit needs to interact with the wayland server. So dead lock. As KRun also calls into the dangerous code path it's no option which leaves us with QProcess to start the processes. A nice side-effect is that we no don't need to link KF5::Service any more from kwin_core. Now once Plasma and Notification don't use it any more, it will be gone completely.
2015-07-07 15:35:57 +00:00
m_environment.insert(QStringLiteral("DISPLAY"), QString::fromUtf8(qgetenv("DISPLAY")));
[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);
[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->setProcessEnvironment(m_environment);
auto finishedSignal = static_cast<void (QProcess::*)(int, QProcess::ExitStatus)>(&QProcess::finished);
connect(p, finishedSignal, this, &ApplicationWayland::quit);
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);
Port away from KToolInvocation The problem with KToolInvocation is that it creates a dead lock on Wayland in case kdeinit is not already running. It starts kdeinit and does a QProcess::waitForFinished and our kdeinit needs to interact with the wayland server. So dead lock. As KRun also calls into the dangerous code path it's no option which leaves us with QProcess to start the processes. A nice side-effect is that we no don't need to link KF5::Service any more from kwin_core. Now once Plasma and Notification don't use it any more, it will be gone completely.
2015-07-07 15:35:57 +00:00
p->setProcessEnvironment(m_environment);
[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);
}
}
[wayland] Drop threaded eglInitialize hack The hack to perform the first eglInitialize in a thread is no longer needed, as our internal QPA plugin is either able to share the EGLDisplay or performs the potentially blocking eglInitialize in a thread.
2015-08-18 06:21:23 +00:00
createWorkspace();
Xcb::sync(); // Trigger possible errors, there's still a chance to abort
notifyKSplash();
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] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
void ApplicationWayland::createX11Connection()
[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
{
int screenNumber = 0;
xcb_connection_t *c = nullptr;
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
if (m_xcbConnectionFd == -1) {
[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
c = xcb_connect(nullptr, &screenNumber);
} else {
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
c = xcb_connect_to_fd(m_xcbConnectionFd, nullptr);
[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
}
[kwin_wayland] Move starting Xwayland into performStartup
2015-02-20 10:53:25 +00:00
if (int error = xcb_connection_has_error(c)) {
std::cerr << "FATAL ERROR: Creating connection to XServer failed: " << error << std::endl;
[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
exit(1);
return;
}
setX11Connection(c);
// we don't support X11 multi-head in Wayland
setX11ScreenNumber(screenNumber);
setX11RootWindow(defaultScreen()->root);
}
[wayland] Use QProcess to start XWayland server The code didn't use QProcess as in the early days of main_wayland.cpp Xwayland had to be started before the QGuiApplication was constructed. As this requirement doesn't exist any more we can use QProcess and improve the interaction by e.g. provide useful error messages if Xwayland couldn't be started.
2015-05-21 13:11:11 +00:00
void ApplicationWayland::startXwaylandServer()
[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
{
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
disconnect(Compositor::self(), &Compositor::sceneCreated, this, &ApplicationWayland::startXwaylandServer);
[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
int pipeFds[2];
if (pipe(pipeFds) != 0) {
[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
std::cerr << "FATAL ERROR failed to create pipe to start Xwayland " << std::endl;
[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
exit(1);
[wayland] Use QProcess to start XWayland server The code didn't use QProcess as in the early days of main_wayland.cpp Xwayland had to be started before the QGuiApplication was constructed. As this requirement doesn't exist any more we can use QProcess and improve the interaction by e.g. provide useful error messages if Xwayland couldn't be started.
2015-05-21 13:11:11 +00:00
return;
}
int sx[2];
if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0, sx) < 0) {
std::cerr << "FATAL ERROR: failed to open socket to open XCB connection" << std::endl;
exit(1);
return;
}
int fd = dup(sx[1]);
if (fd < 0) {
std::cerr << "FATAL ERROR: failed to open socket to open XCB connection" << std::endl;
exit(20);
return;
[kwin_wayland] Add config option to start an X Server KWin_Wayland still needs an X-Server. To simplify the development setup the required X-Server can be started through a command line argument together with KWin. Unfortunately the command line arguments processing needs to be done by hand as QCommandLineParser only allows processing after QApplication is created which requires the started X Server. The nested X-Server is started by forking the application and using execlp to load the binary. In addition a pipe is created to allow the X-Server to write the display number to once it's ready to connect and by that KWin is ready to create the QApplication.
2014-08-12 13:27:35 +00:00
}
[wayland] Use QProcess to start XWayland server The code didn't use QProcess as in the early days of main_wayland.cpp Xwayland had to be started before the QGuiApplication was constructed. As this requirement doesn't exist any more we can use QProcess and improve the interaction by e.g. provide useful error messages if Xwayland couldn't be started.
2015-05-21 13:11:11 +00:00
const int waylandSocket = waylandServer()->createXWaylandConnection();
if (waylandSocket == -1) {
std::cerr << "FATAL ERROR: failed to open socket for Xwayland" << std::endl;
exit(1);
return;
}
const int wlfd = dup(waylandSocket);
if (wlfd < 0) {
std::cerr << "FATAL ERROR: failed to open socket for Xwayland" << std::endl;
[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
exit(20);
[wayland] Use QProcess to start XWayland server The code didn't use QProcess as in the early days of main_wayland.cpp Xwayland had to be started before the QGuiApplication was constructed. As this requirement doesn't exist any more we can use QProcess and improve the interaction by e.g. provide useful error messages if Xwayland couldn't be started.
2015-05-21 13:11:11 +00:00
return;
[kwin_wayland] Add config option to start an X Server KWin_Wayland still needs an X-Server. To simplify the development setup the required X-Server can be started through a command line argument together with KWin. Unfortunately the command line arguments processing needs to be done by hand as QCommandLineParser only allows processing after QApplication is created which requires the started X Server. The nested X-Server is started by forking the application and using execlp to load the binary. In addition a pipe is created to allow the X-Server to write the display number to once it's ready to connect and by that KWin is ready to create the QApplication.
2014-08-12 13:27:35 +00:00
}
[wayland] Use QProcess to start XWayland server The code didn't use QProcess as in the early days of main_wayland.cpp Xwayland had to be started before the QGuiApplication was constructed. As this requirement doesn't exist any more we can use QProcess and improve the interaction by e.g. provide useful error messages if Xwayland couldn't be started.
2015-05-21 13:11:11 +00:00
m_xcbConnectionFd = sx[0];
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
m_xwaylandProcess = new Process(kwinApp());
[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
m_xwaylandProcess->setProcessChannelMode(QProcess::ForwardedErrorChannel);
[wayland] Use QProcess to start XWayland server The code didn't use QProcess as in the early days of main_wayland.cpp Xwayland had to be started before the QGuiApplication was constructed. As this requirement doesn't exist any more we can use QProcess and improve the interaction by e.g. provide useful error messages if Xwayland couldn't be started.
2015-05-21 13:11:11 +00:00
m_xwaylandProcess->setProgram(QStringLiteral("Xwayland"));
[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 env = m_environment;
[wayland] Use QProcess to start XWayland server The code didn't use QProcess as in the early days of main_wayland.cpp Xwayland had to be started before the QGuiApplication was constructed. As this requirement doesn't exist any more we can use QProcess and improve the interaction by e.g. provide useful error messages if Xwayland couldn't be started.
2015-05-21 13:11:11 +00:00
env.insert("WAYLAND_SOCKET", QByteArray::number(wlfd));
m_xwaylandProcess->setProcessEnvironment(env);
m_xwaylandProcess->setArguments({QStringLiteral("-displayfd"),
QString::number(pipeFds[1]),
QStringLiteral("-rootless"),
QStringLiteral("-wm"),
QString::number(fd)});
[wayland] Don't exit due to Xwayland exiting on tear down Our Xwayland exit error handler should not run during tearing down Xwayland. Yes we expect Xwayland to exit as a response to KWin telling it to exit.
2015-11-12 13:05:09 +00:00
m_xwaylandFailConnection = connect(m_xwaylandProcess, static_cast<void (QProcess::*)(QProcess::ProcessError)>(&QProcess::error), this,
[wayland] Use QProcess to start XWayland server The code didn't use QProcess as in the early days of main_wayland.cpp Xwayland had to be started before the QGuiApplication was constructed. As this requirement doesn't exist any more we can use QProcess and improve the interaction by e.g. provide useful error messages if Xwayland couldn't be started.
2015-05-21 13:11:11 +00:00
[] (QProcess::ProcessError error) {
if (error == QProcess::FailedToStart) {
std::cerr << "FATAL ERROR: failed to start Xwayland" << std::endl;
} else {
std::cerr << "FATAL ERROR: Xwayland failed, going to exit now" << std::endl;
}
exit(1);
}
);
const int xDisplayPipe = pipeFds[0];
connect(m_xwaylandProcess, &QProcess::started, this,
[this, xDisplayPipe] {
QFutureWatcher<void> *watcher = new QFutureWatcher<void>(this);
QObject::connect(watcher, &QFutureWatcher<void>::finished, this, &ApplicationWayland::continueStartupWithX, Qt::QueuedConnection);
QObject::connect(watcher, &QFutureWatcher<void>::finished, watcher, &QFutureWatcher<void>::deleteLater, Qt::QueuedConnection);
watcher->setFuture(QtConcurrent::run(readDisplay, xDisplayPipe));
}
);
m_xwaylandProcess->start();
[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
close(pipeFds[1]);
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
}
[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
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
static void readDisplay(int pipe)
{
[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
QFile readPipe;
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
if (!readPipe.open(pipe, QIODevice::ReadOnly)) {
std::cerr << "FATAL ERROR failed to open pipe to start X Server" << std::endl;
[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
exit(1);
}
QByteArray displayNumber = readPipe.readLine();
displayNumber.prepend(QByteArray(":"));
displayNumber.remove(displayNumber.size() -1, 1);
[kwin_wayland] Fix printing out the X11 display std::endl was missing.
2014-11-07 13:58:21 +00:00
std::cout << "X-Server started on display " << displayNumber.constData() << std::endl;
[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
setenv("DISPLAY", displayNumber.constData(), true);
// close our pipe
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
close(pipe);
[kwin_wayland] Add config option to start an X Server KWin_Wayland still needs an X-Server. To simplify the development setup the required X-Server can be started through a command line argument together with KWin. Unfortunately the command line arguments processing needs to be done by hand as QCommandLineParser only allows processing after QApplication is created which requires the started X Server. The nested X-Server is started by forking the application and using execlp to load the binary. In addition a pipe is created to allow the X-Server to write the display number to once it's ready to connect and by that KWin is ready to create the QApplication.
2014-08-12 13:27:35 +00:00
}
[wayland] 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()));
if (parent.isSymLink() && parent.symLinkTarget().endsWith(QLatin1String("/gdb"))) {
// debugger, don't adjust
return;
}
// disable ptrace in kwin_wayland
prctl(PR_SET_DUMPABLE, 0);
#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
{
[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();
[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);
[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");
[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
qunsetenv("QT_IM_MODULE");
[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");
[wayland] Force Qt::AA_NoHighDpiScaling on Qt 5.6 We already unset QT_DEVICE_PIXEL_RATIO to ensure to keep out of high dpi scaling. Now with Qt 5.6 we also need to set the attribute. Without we crash on startup as we don't have a screen that early and well Qt doesn't check whether it's null.
2015-10-29 09:08:23 +00:00
#if (QT_VERSION >= QT_VERSION_CHECK(5, 6, 0))
[wayland] Use Qt::AA_DisableHighDpiScaling in Qt 5.6 Follow the change of Qt 5.6 branch, see below https://codereview.qt-project.org/#/c/127895/ REVIEW: 126008
2015-11-09 17:21:50 +00:00
QCoreApplication::setAttribute(Qt::AA_DisableHighDpiScaling);
[wayland] Force Qt::AA_NoHighDpiScaling on Qt 5.6 We already unset QT_DEVICE_PIXEL_RATIO to ensure to keep out of high dpi scaling. Now with Qt 5.6 we also need to set the attribute. Without we crash on startup as we don't have a screen that early and well Qt doesn't check whether it's null.
2015-10-29 09:08:23 +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
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();
[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 hasWindowedOption = hasPlugin(KWin::s_x11Plugin) || hasPlugin(KWin::s_waylandPlugin);
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 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 windowedOption(QStringLiteral("windowed"),
i18n("Use a nested compositor in windowed mode."));
[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"));
framebufferDeviceOption.setDefaultValue(QStringLiteral("/dev/fb0"));
[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));
[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"),
QStringLiteral("height"));
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 (hasWindowedOption) {
[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(windowedOption);
}
[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);
}
[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
#if HAVE_INPUT
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
#endif
#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);
[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);
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
QCommandLineOption noActivitiesOption(QStringLiteral("no-kactivities"),
i18n("Disable KActivities integration."));
parser.addOption(noActivitiesOption);
#endif
[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
if (parser.isSet(noActivitiesOption)) {
a.setUseKActivities(false);
}
#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
#if HAVE_INPUT
KWin::Application::setUseLibinput(parser.isSet(libinputOption));
#endif
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;
[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;
}
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);
}
}
[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 (hasWindowedOption && parser.isSet(windowedOption)) {
if (hasX11Option && parser.isSet(x11DisplayOption)) {
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(x11DisplayOption).toUtf8();
[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
} else if (!(hasWaylandOption && parser.isSet(waylandDisplayOption))) {
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 = qgetenv("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
}
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 (!deviceIdentifier.isEmpty()) {
[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_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
} else if (hasWaylandOption) {
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 (parser.isSet(waylandDisplayOption)) {
deviceIdentifier = parser.value(waylandDisplayOption).toUtf8();
[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
} else {
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 = qgetenv("WAYLAND_DISPLAY");
}
if (!deviceIdentifier.isEmpty()) {
[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_waylandPlugin;
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 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] 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;
}
server->init(parser.value(waylandSocketOption).toUtf8(), flags);
[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
[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 (qobject_cast<KWin::AbstractBackend*>((*pluginIt).instantiate())) {
[wayland] Determine whether libinput is needed from plugin metadata If the backend specifies { "input": false } in it's plugin metadata, it means that it does not handle input by itself. In that case we can enforce libinput. With this change one does no longer need to specify --libinput when starting kwin_wayland on the drm or fbdev backend. So kwin_wayland --xwayland will bring up a fully functional kwin_wayland on drm platform.
2015-07-16 08:54:29 +00:00
#if HAVE_INPUT
[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
// check whether it needs libinput
const QJsonObject &metaData = (*pluginIt).rawData();
auto it = metaData.find(QStringLiteral("input"));
optimize string operations -use qstringliteral only when necessary (i.e. not in concat or comparison) -use qbytearray instead of qstring when dealing with latin1 input and output (glplatform) -use qstringref to extract numbers from strings (glplatform) -define qt_use_qstringbuilder to optimize all string concatenations -anidata: use ctor init lists, add windowType member initialization REVIEW: 125933
2015-11-05 14:14:06 +00:00
if (it != metaData.end()) {
[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 ((*it).isBool()) {
if (!(*it).toBool()) {
std::cerr << "Backend does not support input, enforcing libinput support" << std::endl;
KWin::Application::setUseLibinput(true);
[wayland] Determine whether libinput is needed from plugin metadata If the backend specifies { "input": false } in it's plugin metadata, it means that it does not handle input by itself. In that case we can enforce libinput. With this change one does no longer need to specify --libinput when starting kwin_wayland on the drm or fbdev backend. So kwin_wayland --xwayland will bring up a fully functional kwin_wayland on drm platform.
2015-07-16 08:54:29 +00:00
}
}
Create a plugin for each of the wayland backends Each of the backends becomes a plugin. This allows kwin_wayland to load the requested plugin and kwin itself doesn't need to link all the libraries needed. E.g. libdrm is no longer linked if running kwin_x11. Also this allows to create backends for the non-standard EGL platforms (examples could be raspberrypi or Android devices).
2015-05-05 15:58:09 +00:00
}
[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
#endif
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 (!server->backend()) {
std::cerr << "FATAL ERROR: could not instantiate a backend" << std::endl;
return 1;
}
server->backend()->setParent(server);
if (!deviceIdentifier.isEmpty()) {
server->backend()->setDeviceIdentifier(deviceIdentifier);
}
if (initialWindowSize.isValid()) {
server->backend()->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
}
[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
server->backend()->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