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

624 lines
23 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"
[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"
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>
#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>
[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] Ensure QWindowSystemInterface::sendWindowSystemEvents gets called in EventDispatcher KWin used the wrong event dispatcher: QEventDispatcherUNIX insted of QUnixEventDispatcherQPA. This caused QWindow related events never to be send to their destination. Which is one of the reasons why KWin's own windows are not shown at all. As we cannot easily use QUnixEventDispatcherQPA we do the same as that class. Inherit from QEventDispatcherUNIX and call into QWindowSystemInterface::sendWindowSystemEvents.
2015-05-18 09:09:48 +00:00
#include <qpa/qwindowsysteminterface.h>
[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
[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();
}
[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()
{
[wayland] Ensure Compositor is destroyed early enough If startup fails and there is no Workspace the Compositor was destroyed as a child of Application with the result of being destroyed after the Wayland server resulting in a crash. If the Workspace gets created the Compositor will be destroyed by the Workspace, so there's no need to destroy it early.
2015-05-27 07:09:05 +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
destroyWorkspace();
[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();
[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] 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();
m_xwaylandProcess->waitForFinished();
}
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
[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();
[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
[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
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");
QProcess *p = new QProcess(this);
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] 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
QProcess *p = new QProcess(this);
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();
waylandServer()->createDummyQtWindow();
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] Implement notify in ApplicationWayland If we get an Expose event for any QWindow we need to ensure that all wayland events on both client (Qt) and server (KWin) side are dispatched. Otherwise it could happen that Qt starts rendering although the last frame callback has not yet been emitted, causing the main gui thread to be blocked.
2015-05-20 11:11:17 +00:00
bool ApplicationWayland::notify(QObject *o, QEvent *e)
{
[wayland] Ensure our own windows don't have flag Qt::X11BypassWindowManagerHint The QtWayland QPA plugin does not create windows with X11BypassWindowManagerHint which means that KWin's internal windows are not shown at all. Even worse in QtQuick it can result in a freeze due to blocking wait for a frame rendered which can just never happen. As windows could be created by e.g. scripts or look and feel packages we cannot ensure that the flag will never be set in source code. Thus we use ApplicationWayland::notify to filter for Show events and check whether the window to be shown is bypassing window manager hits. If it is, we unset the flag, destroy the window and show a new one.
2015-05-26 11:53:23 +00:00
if (QWindow *w = qobject_cast< QWindow* >(o)) {
[wayland] Implement notify in ApplicationWayland If we get an Expose event for any QWindow we need to ensure that all wayland events on both client (Qt) and server (KWin) side are dispatched. Otherwise it could happen that Qt starts rendering although the last frame callback has not yet been emitted, causing the main gui thread to be blocked.
2015-05-20 11:11:17 +00:00
if (e->type() == QEvent::Expose) {
// ensure all Wayland events both on client and server side are dispatched
// otherwise it is possible that Qt starts rendering and blocks the main gui thread
// as it waits for the callback of the last frame
waylandServer()->dispatch();
}
}
return Application::notify(o, e);
}
[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
{
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];
m_xwaylandProcess = new QProcess(kwinApp());
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)});
connect(m_xwaylandProcess, static_cast<void (QProcess::*)(QProcess::ProcessError)>(&QProcess::error), this,
[] (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] Ensure QWindowSystemInterface::sendWindowSystemEvents gets called in EventDispatcher KWin used the wrong event dispatcher: QEventDispatcherUNIX insted of QUnixEventDispatcherQPA. This caused QWindow related events never to be send to their destination. Which is one of the reasons why KWin's own windows are not shown at all. As we cannot easily use QUnixEventDispatcherQPA we do the same as that class. Inherit from QEventDispatcherUNIX and call into QWindowSystemInterface::sendWindowSystemEvents.
2015-05-18 09:09:48 +00:00
EventDispatcher::EventDispatcher(QObject *parent)
: QEventDispatcherUNIX(parent)
{
}
EventDispatcher::~EventDispatcher() = default;
bool EventDispatcher::processEvents(QEventLoop::ProcessEventsFlags flags)
{
[wayland] Flush QtWaylands wl_display and KWin's wayland server when processing events QtWayland and mesa might dead lock KWin if we start rendering a QWindow before Qt/Mesa got the last frame callback. They perform blocking wayland event reading on the main gui thread which makes it impossible for KWin to do the compositing and send the callback. To workaround this problem we fake a frameRendered directly after each damage event for a Qt internal window. Unfortunately this is not yet completely sufficient, thus we also need to ensure that the wayland events are processed before any events are processed which would cause a repaint and block. Thus we first flush QtWayland's wl_display and then our Server connection. If there were any damage events we can be sure that the frameRendered is sent before Qt attempts to render.
2015-05-18 09:33:00 +00:00
waylandServer()->dispatch();
[wayland] Ensure QWindowSystemInterface::sendWindowSystemEvents gets called in EventDispatcher KWin used the wrong event dispatcher: QEventDispatcherUNIX insted of QUnixEventDispatcherQPA. This caused QWindow related events never to be send to their destination. Which is one of the reasons why KWin's own windows are not shown at all. As we cannot easily use QUnixEventDispatcherQPA we do the same as that class. Inherit from QEventDispatcherUNIX and call into QWindowSystemInterface::sendWindowSystemEvents.
2015-05-18 09:09:48 +00:00
const bool didSendEvents = QEventDispatcherUNIX::processEvents(flags);
return QWindowSystemInterface::sendWindowSystemEvents(flags) || didSendEvents;
}
bool EventDispatcher::hasPendingEvents()
{
return QEventDispatcherUNIX::hasPendingEvents() || QWindowSystemInterface::windowSystemEventsQueued();
}
[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
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;
}
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
{
[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
// process command line arguments to figure out whether we have to start Xwayland and the Wayland socket
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
QByteArray waylandSocket;
[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
for (int i = 1; i < argc; ++i) {
small string optimizations
2015-01-24 02:13:45 +00:00
QByteArray arg = QByteArray::fromRawData(argv[i], qstrlen(argv[i]));
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 (arg == "--socket" || arg == "-s") {
if (++i < argc) {
waylandSocket = QByteArray::fromRawData(argv[i], qstrlen(argv[i]));
}
continue;
}
if (arg.startsWith("--socket=")) {
waylandSocket = arg.mid(9);
}
[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
}
[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
// set our own event dispatcher to be able to dispatch events before the event loop is started
[wayland] Ensure QWindowSystemInterface::sendWindowSystemEvents gets called in EventDispatcher KWin used the wrong event dispatcher: QEventDispatcherUNIX insted of QUnixEventDispatcherQPA. This caused QWindow related events never to be send to their destination. Which is one of the reasons why KWin's own windows are not shown at all. As we cannot easily use QUnixEventDispatcherQPA we do the same as that class. Inherit from QEventDispatcherUNIX and call into QWindowSystemInterface::sendWindowSystemEvents.
2015-05-18 09:09:48 +00:00
QAbstractEventDispatcher *eventDispatcher = new KWin::EventDispatcher();
[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
QCoreApplication::setEventDispatcher(eventDispatcher);
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::WaylandServer *server = KWin::WaylandServer::create(nullptr);
server->init(waylandSocket);
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
sigset_t userSiganls;
sigemptyset(&userSiganls);
sigaddset(&userSiganls, SIGUSR1);
sigaddset(&userSiganls, SIGUSR2);
pthread_sigmask(SIG_BLOCK, &userSiganls, 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();
environment.insert(QStringLiteral("WAYLAND_DISPLAY"), server->display()->socketName());
[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
#if (QT_VERSION < QT_VERSION_CHECK(5, 4, 2))
// TODO: remove warning once we depend on Qt 5.5
qWarning() << "QtWayland 5.4.2 required, application might freeze if not present!";
#endif
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");
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] 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
a.setProcessStartupEnvironment(environment);
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
Let the fun begin: start a WaylandServer in kwin_wayland The WaylandServer is at the moment only used to support starting an Xwayland. It does not support Wayland clients yet, so don't get excited. For Xwayland it's using the trick of creating the Display before the QApplication is created with manual event dispatching.
2015-02-09 12:28:37 +00:00
server->setParent(&a);
Create dedicated kwin_x11 and kwin_wayland binaries All of kwin except the main function goes into a new (private) library called kwin. Two new kdeinit_executables are created: * kwin_x11 * kwin_wayland Both only use a dedicated main_x11.cpp and main_wayland.cpp with the main function and a KWin::Application subclass and linking the new kwin library. The main idea behind this is to be able to perform more sane sanity checks. E.g. on Wayland we don't need to first test whether we can create an X11 connection. Instead we should abort if we cannot connect to the Wayland display. Also the multi-head checks are not needed on Wayland, etc. etc. As most of that code is in the main function to simplify it's better to split. This will also make it easier to diverge more easily in future. The Wayland variant can introduce more suited command line arguments for example. This already started by having the --replace option only available in X11 variant. The Wayland backend is still a window manager, but doesn't claim the manager selection.
2014-08-12 07:08:48 +00:00
KWin::Application::createAboutData();
[xwayland] Add a dedicated --xwayland option to kwin_wayland The --xwayland option starts a rootles Xwayland server. If a rootless Xwayland server is used OperationModeXwayland is used which is introduced with this change as well.
2015-01-09 15:00:16 +00:00
QCommandLineOption xwaylandOption(QStringLiteral("xwayland"),
[xwayland] Drop options to start Xephyr or Xvfb Only --xwayland stays supported. The option --displayfd and --rootless are always set. Simplifies the feature matrix and the other X servers don't make any sense now that we can start a proper rootless Xwayland.
2015-02-09 12:40:01 +00:00
i18n("Start a rootless Xwayland server."));
Let the fun begin: start a WaylandServer in kwin_wayland The WaylandServer is at the moment only used to support starting an Xwayland. It does not support Wayland clients yet, so don't get excited. For Xwayland it's using the trick of creating the Display before the QApplication is created with manual event dispatching.
2015-02-09 12:28:37 +00:00
QCommandLineOption waylandSocketOption(QStringList{QStringLiteral("s"), QStringLiteral("socket")},
i18n("Name of the Wayland socket to listen on. If not set \"wayland-0\" is used."),
QStringLiteral("socket"));
[wayland] Add an X11 output backend This new backend allows to start a kwin_wayland server nested on an X-Server by using a normal X11 window as output. This allows testing kwin_wayland without needing to start another Wayland server first. The behavior is triggered by using new command line arguments: --windowed --x11-display=<:0> With optional --width and --height arguments. In this mode the WaylandBackend is not created at all. So far the backend is not fully integrated yet and only the QPainter backend supports this mode.
2015-03-19 07:29:34 +00:00
QCommandLineOption 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 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));
[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] 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
parser.addOption(windowedOption);
parser.addOption(x11DisplayOption);
[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
parser.addOption(waylandDisplayOption);
[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
parser.addOption(framebufferOption);
parser.addOption(framebufferDeviceOption);
[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
parser.addOption(widthOption);
parser.addOption(heightOption);
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"));
parser.addOption(hwcomposerOption);
#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."));
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 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);
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 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
if (parser.isSet(windowedOption) && parser.isSet(framebufferOption)) {
std::cerr << "FATAL ERROR Cannot have both --windowed and --framebuffer" << std::endl;
return 1;
}
[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
if (parser.isSet(drmOption) && (parser.isSet(windowedOption) || parser.isSet(framebufferOption))) {
std::cerr << "FATAL ERROR Cannot have both --windowed/--framebuffer and --drm" << std::endl;
return 1;
}
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(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] 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
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] 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
if (parser.isSet(windowedOption)) {
[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
if (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] 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
} else if (!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;
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
} else {
if (parser.isSet(waylandDisplayOption)) {
deviceIdentifier = parser.value(waylandDisplayOption).toUtf8();
} else if (!parser.isSet(x11DisplayOption)) {
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] 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
if (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
if (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
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();
}
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
const auto pluginCandidates = KPluginLoader::findPlugins(QStringLiteral("org.kde.kwin.waylandbackends"),
[&pluginName] (const KPluginMetaData &plugin) {
return plugin.pluginId() == pluginName;
}
);
if (pluginCandidates.isEmpty()) {
std::cerr << "FATAL ERROR: could not find a backend" << std::endl;
return 1;
}
for (const auto &candidate: pluginCandidates) {
if (qobject_cast<KWin::AbstractBackend*>(candidate.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
// check whether it needs libinput
const QJsonObject &metaData = candidate.rawData();
auto it = metaData.find(QStringLiteral("input"));
if (it != metaData.constEnd()) {
if ((*it).isBool()) {
if (!(*it).toBool()) {
std::cerr << "Backend does not support input, enforcing libinput support" << std::endl;
KWin::Application::setUseLibinput(true);
}
}
}
#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
break;
}
}
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 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);
[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