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

274 lines
9 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"
#include <config-kwin.h>
// kwin
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
#include "wayland_backend.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"
// KDE
#include <KLocalizedString>
// Qt
#include <qplatformdefs.h>
#include <QCommandLineParser>
[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>
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
[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>
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();
}
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()
{
destroyWorkspace();
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
delete Wayland::WaylandBackend::self();
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
// TODO: only if we support X11
Xcb::setInputFocus(XCB_INPUT_FOCUS_POINTER_ROOT);
}
void ApplicationWayland::performStartup()
{
// we don't support X11 multi-head in Wayland
Application::setX11ScreenNumber(0);
// we need to do an XSync here, otherwise the QPA might crash us later on
// TODO: remove
Xcb::sync();
createAtoms();
setupEventFilters();
// first load options - done internally by a different thread
createOptions();
// 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);
}
// try creating the Wayland Backend
Wayland::WaylandBackend *backend = Wayland::WaylandBackend::create();
[kwin-wayland] Create dedicated thread for wayland connection The Wayland event queue is moved into a dedicated thread and a new class is created for just creating the connection and listening for events. The WaylandBackend creates the thread and uses an event queue for the main thread. REVIEW: 119761
2014-08-13 10:54:02 +00:00
connect(backend, &Wayland::WaylandBackend::connectionFailed, this,
[] () {
fputs(i18n("kwin_wayland: could not connect to Wayland Server, ensure WAYLAND_DISPLAY is set.\n").toLocal8Bit().constData(), stderr);
::exit(1);
}
);
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
createWorkspace();
Xcb::sync(); // Trigger possible errors, there's still a chance to abort
notifyKSplash();
}
[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
/**
* Starts the X-Server with binary name @p process on @p display.
* The new process is started by forking into it.
**/
static void startXServer(const QByteArray &process, const QByteArray &display)
{
int pipeFds[2];
if (pipe(pipeFds) != 0) {
std::cerr << "FATAL ERROR failed to create pipe to start X Server "
<< process.constData()
<< " with arguments "
<< display.constData()
<< std::endl;
exit(1);
}
pid_t pid = fork();
if (pid == 0) {
// child process - should be turned into X-Server
// writes to pipe, closes read side
close(pipeFds[0]);
char fdbuf[16];
sprintf(fdbuf, "%d", pipeFds[1]);
execlp(process.constData(), process.constData(), "-displayfd", fdbuf, display.constData(), (char *)0);
close(pipeFds[1]);
exit(20);
}
// parent process - this is KWin
// reads from pipe, closes write side
close(pipeFds[1]);
QFile readPipe;
if (!readPipe.open(pipeFds[0], QIODevice::ReadOnly)) {
std::cerr << "FATAL ERROR failed to open pipe to start X Server "
<< process.constData()
<< " with arguments "
<< display.constData()
<< std::endl;
exit(1);
}
QByteArray displayNumber = readPipe.readLine();
displayNumber.prepend(QByteArray(":"));
displayNumber.remove(displayNumber.size() -1, 1);
std::cout << "X-Server started on display " << displayNumber.constData();
setenv("DISPLAY", displayNumber.constData(), true);
// close our pipe
close(pipeFds[0]);
}
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
extern "C"
KWIN_EXPORT int kdemain(int argc, char * argv[])
{
[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
// process command line arguments to figure out whether we have to start an X-Server
bool startXephyr = false;
bool startXvfb = false;
bool startXwayland = false;
QByteArray xDisplay;
QByteArray xServer;
for (int i = 1; i < argc; ++i) {
QByteArray arg = argv[i];
Fix --x-server argument of kwin_wayland
2014-11-05 13:40:38 +00:00
if (arg == "-x" || arg == "--x-server") {
[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
if (++i < argc) {
xServer = argv[i];
}
startXephyr = (xServer == QStringLiteral("xephyr"));
startXvfb = (xServer == QStringLiteral("xvfb"));
startXwayland = (xServer == QStringLiteral("xwayland"));
if (!startXephyr && !startXvfb && !startXwayland) {
fprintf(stderr, "%s: FATAL ERROR unknown X-Server %s specified to start\n",
argv[0], qPrintable(xServer));
exit(1);
}
continue;
}
if (arg == "--display") {
if (++i < argc) {
xDisplay = argv[i];
}
}
}
if (startXephyr) {
KWin::startXServer(QByteArrayLiteral("Xephyr"), xDisplay);
}
if (startXvfb) {
KWin::startXServer(QByteArrayLiteral("Xvfb"), xDisplay);
}
if (startXwayland) {
KWin::startXServer(QByteArrayLiteral("Xwayland"), xDisplay);
}
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::Application::setupLoggingCategoryFilters();
// TODO: check whether we have a wayland connection
// Disable the glib event loop integration, since it seems to be responsible
// for several bug reports about high CPU usage (bug #239963)
setenv("QT_NO_GLIB", "1", true);
// enforce xcb plugin, unfortunately command line switch has precedence
// TODO: ensure it's not xcb once we support the Wayland QPA
setenv("QT_QPA_PLATFORM", "xcb", true);
[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);
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();
KWin::Application::createAboutData();
[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
QCommandLineOption startXServerOption(QStringList({QStringLiteral("x"), QStringLiteral("x-server")}),
i18n("Start a nested X Server."),
QStringLiteral("xephyr|xvfb|xwayland"));
QCommandLineOption x11DisplayOption(QStringLiteral("display"),
i18n("The X11 Display to connect to, required if option x-server is used."),
QStringLiteral("display"));
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);
[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
parser.addOption(startXServerOption);
parser.addOption(x11DisplayOption);
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);
#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
parser.process(a);
a.processCommandLine(&parser);
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 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
// perform sanity checks
// TODO: remove those two
if (a.platformName().toLower() != QStringLiteral("xcb")) {
fprintf(stderr, "%s: FATAL ERROR expecting platform xcb but got platform %s\n",
argv[0], qPrintable(a.platformName()));
exit(1);
}
if (!KWin::display()) {
fprintf(stderr, "%s: FATAL ERROR KWin requires Xlib support in the xcb plugin. Do not configure Qt with -no-xcb-xlib\n",
argv[0]);
exit(1);
}
a.start();
// TODO: is this still needed?
a.registerDBusService();
return a.exec();
}
Reference in a new issue Copy permalink