yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/plugins/qpa/integration.h

61 lines
1.8 KiB
C
Raw Normal View History

[wayland] Add a QPA plugin for kwin_wayland This introduces an own QPA plugin for KWin. QtWayland's plugin is not a good solution for KWin as QtWayland is meant for Wayland clients and not for a Wayland server. Given that it makes more sense to have a very minimal QPA plugin which supports the use cases we actually have. With our own QPA plugin we should be able to improve the following areas: * no need to create Wayland server before QApplication * Qt::BypassWindowManagerHint can be supported * no workaround for creating OpenGL context in main thread * sharing OpenGL context with Qt * OpenGL context for Qt on libhybris backend The plugin supports so far the following features: * creating a QPlatformWindow using KWayland::Client (ShellSurface) * creating a QPlatformBackingStore using a ShmPool * creating a QPlatformOpenGLContext with Wayland::EGL * or creating a QPlatformOpenGLContext which shares with KWin's scene * creating a QPlatformScreen for each KWayland::Client::Output * QPlatformNativeInterface compatible to QtWayland
2015-08-14 14:52:40 +00:00
/********************************************************************
KWin - the KDE window manager
This file is part of the KDE project.
Switch to SPDX license markers The main advantage of SPDX license identifiers over the traditional license headers is that it's more difficult to overlook inappropriate licenses for kwin, for example GPL 3. We also don't have to copy a lot of boilerplate text. In order to create this change, I ran licensedigger -r -c from the toplevel source directory.
2020-08-02 22:10:35 +00:00
SPDX-FileCopyrightText: 2015 Martin Gräßlin <mgraesslin@kde.org>
SPDX-FileCopyrightText: 2019 Vlad Zahorodnii <vlad.zahorodnii@kde.org>
[wayland] Add a QPA plugin for kwin_wayland This introduces an own QPA plugin for KWin. QtWayland's plugin is not a good solution for KWin as QtWayland is meant for Wayland clients and not for a Wayland server. Given that it makes more sense to have a very minimal QPA plugin which supports the use cases we actually have. With our own QPA plugin we should be able to improve the following areas: * no need to create Wayland server before QApplication * Qt::BypassWindowManagerHint can be supported * no workaround for creating OpenGL context in main thread * sharing OpenGL context with Qt * OpenGL context for Qt on libhybris backend The plugin supports so far the following features: * creating a QPlatformWindow using KWayland::Client (ShellSurface) * creating a QPlatformBackingStore using a ShmPool * creating a QPlatformOpenGLContext with Wayland::EGL * or creating a QPlatformOpenGLContext which shares with KWin's scene * creating a QPlatformScreen for each KWayland::Client::Output * QPlatformNativeInterface compatible to QtWayland
2015-08-14 14:52:40 +00:00
Switch to SPDX license markers The main advantage of SPDX license identifiers over the traditional license headers is that it's more difficult to overlook inappropriate licenses for kwin, for example GPL 3. We also don't have to copy a lot of boilerplate text. In order to create this change, I ran licensedigger -r -c from the toplevel source directory.
2020-08-02 22:10:35 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
[wayland] Add a QPA plugin for kwin_wayland This introduces an own QPA plugin for KWin. QtWayland's plugin is not a good solution for KWin as QtWayland is meant for Wayland clients and not for a Wayland server. Given that it makes more sense to have a very minimal QPA plugin which supports the use cases we actually have. With our own QPA plugin we should be able to improve the following areas: * no need to create Wayland server before QApplication * Qt::BypassWindowManagerHint can be supported * no workaround for creating OpenGL context in main thread * sharing OpenGL context with Qt * OpenGL context for Qt on libhybris backend The plugin supports so far the following features: * creating a QPlatformWindow using KWayland::Client (ShellSurface) * creating a QPlatformBackingStore using a ShmPool * creating a QPlatformOpenGLContext with Wayland::EGL * or creating a QPlatformOpenGLContext which shares with KWin's scene * creating a QPlatformScreen for each KWayland::Client::Output * QPlatformNativeInterface compatible to QtWayland
2015-08-14 14:52:40 +00:00
*********************************************************************/
#ifndef KWIN_QPA_INTEGRATION_H
#define KWIN_QPA_INTEGRATION_H
#include <epoxy/egl.h>
Fix the build on armhf/aarch64 Summary: qopengl.h redeclares the functions defined in the epoxy/gl.h and it results in the build error. this is similar to other .cpp files where epoxy/gl.h is used. See: https://build.neon.kde.org/job/xenial_unstable_plasma_kwin_bin_armhf/157 Reviewers: #plasma, graesslin Reviewed By: #plasma, graesslin Subscribers: plasma-devel, kwin, #kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D10762
2018-03-06 03:55:13 +00:00
#include "fixqopengl.h"
[wayland] Add a QPA plugin for kwin_wayland This introduces an own QPA plugin for KWin. QtWayland's plugin is not a good solution for KWin as QtWayland is meant for Wayland clients and not for a Wayland server. Given that it makes more sense to have a very minimal QPA plugin which supports the use cases we actually have. With our own QPA plugin we should be able to improve the following areas: * no need to create Wayland server before QApplication * Qt::BypassWindowManagerHint can be supported * no workaround for creating OpenGL context in main thread * sharing OpenGL context with Qt * OpenGL context for Qt on libhybris backend The plugin supports so far the following features: * creating a QPlatformWindow using KWayland::Client (ShellSurface) * creating a QPlatformBackingStore using a ShmPool * creating a QPlatformOpenGLContext with Wayland::EGL * or creating a QPlatformOpenGLContext which shares with KWin's scene * creating a QPlatformScreen for each KWayland::Client::Output * QPlatformNativeInterface compatible to QtWayland
2015-08-14 14:52:40 +00:00
#include <fixx11h.h>
#include <qpa/qplatformintegration.h>
#include <QObject>
namespace KWin
{
namespace QPA
{
[plugins/qpa] Add a dummy screen on startup Qt has problems initializing everything correctly if there is no screen at startup. E.g. the breeze widget style tries to initialize some pixmaps and this fails. In worst case hitting asserts in Qt (debug build). This change creates a dummy screen which gets destroyed as soon as there is a real screen. Reviewed-By: notmart and sebas
2016-03-10 16:02:06 +00:00
class Screen;
[wayland] Add a QPA plugin for kwin_wayland This introduces an own QPA plugin for KWin. QtWayland's plugin is not a good solution for KWin as QtWayland is meant for Wayland clients and not for a Wayland server. Given that it makes more sense to have a very minimal QPA plugin which supports the use cases we actually have. With our own QPA plugin we should be able to improve the following areas: * no need to create Wayland server before QApplication * Qt::BypassWindowManagerHint can be supported * no workaround for creating OpenGL context in main thread * sharing OpenGL context with Qt * OpenGL context for Qt on libhybris backend The plugin supports so far the following features: * creating a QPlatformWindow using KWayland::Client (ShellSurface) * creating a QPlatformBackingStore using a ShmPool * creating a QPlatformOpenGLContext with Wayland::EGL * or creating a QPlatformOpenGLContext which shares with KWin's scene * creating a QPlatformScreen for each KWayland::Client::Output * QPlatformNativeInterface compatible to QtWayland
2015-08-14 14:52:40 +00:00
class Integration : public QObject, public QPlatformIntegration
{
Q_OBJECT
public:
explicit Integration();
Run clang-tidy with modernize-use-override check Summary: Currently code base of kwin can be viewed as two pieces. One is very ancient, and the other one is more modern, which uses new C++ features. The main problem with the ancient code is that it was written before C++11 era. So, no override or final keywords, lambdas, etc. Quite recently, KDE compiler settings were changed to show a warning if a virtual method has missing override keyword. As you might have already guessed, this fired back at us because of that ancient code. We had about 500 new compiler warnings. A "solution" was proposed to that problem - disable -Wno-suggest-override and the other similar warning for clang. It's hard to call a solution because those warnings are disabled not only for the old code, but also for new. This is not what we want! The main argument for not actually fixing the problem was that git history will be screwed as well because of human factor. While good git history is a very important thing, we should not go crazy about it and block every change that somehow alters git history. git blame allows to specify starting revision for a reason. The other argument (human factor) can be easily solved by using tools such as clang-tidy. clang-tidy is a clang-based linter for C++. It can be used for various things, e.g. fixing coding style(e.g. add missing braces to if statements, readability-braces-around-statements check), or in our case add missing override keywords. Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, apol, romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22371
2019-07-22 16:52:26 +00:00
~Integration() override;
[wayland] Add a QPA plugin for kwin_wayland This introduces an own QPA plugin for KWin. QtWayland's plugin is not a good solution for KWin as QtWayland is meant for Wayland clients and not for a Wayland server. Given that it makes more sense to have a very minimal QPA plugin which supports the use cases we actually have. With our own QPA plugin we should be able to improve the following areas: * no need to create Wayland server before QApplication * Qt::BypassWindowManagerHint can be supported * no workaround for creating OpenGL context in main thread * sharing OpenGL context with Qt * OpenGL context for Qt on libhybris backend The plugin supports so far the following features: * creating a QPlatformWindow using KWayland::Client (ShellSurface) * creating a QPlatformBackingStore using a ShmPool * creating a QPlatformOpenGLContext with Wayland::EGL * or creating a QPlatformOpenGLContext which shares with KWin's scene * creating a QPlatformScreen for each KWayland::Client::Output * QPlatformNativeInterface compatible to QtWayland
2015-08-14 14:52:40 +00:00
bool hasCapability(Capability cap) const override;
QPlatformWindow *createPlatformWindow(QWindow *window) const override;
[plugins/qpa] Implement native offscreen surface Summary: Depending on whether the underlying platform supports offscreen surfaces, QOffscreenSurface may create an invisible QWindow. In our case that's the case, for each offscreen surface a native window is created. This may lead to some funky results related to window decorations, see bug 407612. There are several ways to implement offscreen surfaces - either use pbuffers or utilize a surfaceless context extension. For the sake of simplicity this change sticks with pbuffers, but it's a good idea to support both methods. CCBUG: 407612 Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, alexeymin, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22150
2019-07-01 18:34:38 +00:00
QPlatformOffscreenSurface *createPlatformOffscreenSurface(QOffscreenSurface *surface) const override;
[wayland] Add a QPA plugin for kwin_wayland This introduces an own QPA plugin for KWin. QtWayland's plugin is not a good solution for KWin as QtWayland is meant for Wayland clients and not for a Wayland server. Given that it makes more sense to have a very minimal QPA plugin which supports the use cases we actually have. With our own QPA plugin we should be able to improve the following areas: * no need to create Wayland server before QApplication * Qt::BypassWindowManagerHint can be supported * no workaround for creating OpenGL context in main thread * sharing OpenGL context with Qt * OpenGL context for Qt on libhybris backend The plugin supports so far the following features: * creating a QPlatformWindow using KWayland::Client (ShellSurface) * creating a QPlatformBackingStore using a ShmPool * creating a QPlatformOpenGLContext with Wayland::EGL * or creating a QPlatformOpenGLContext which shares with KWin's scene * creating a QPlatformScreen for each KWayland::Client::Output * QPlatformNativeInterface compatible to QtWayland
2015-08-14 14:52:40 +00:00
QPlatformBackingStore *createPlatformBackingStore(QWindow *window) const override;
QAbstractEventDispatcher *createEventDispatcher() const override;
QPlatformFontDatabase *fontDatabase() const override;
QStringList themeNames() const override;
QPlatformTheme *createPlatformTheme(const QString &name) const override;
QPlatformOpenGLContext *createPlatformOpenGLContext(QOpenGLContext *context) const override;
Integrate QtVirtualKeyboard into KWin/Wayland Summary: The idea is to have KWin provide a virtual keyboard. To support this KWin uses the QT_IM_MODULE qtvirtualkeyboard and makes sure that the QPA plugin loads it. KWin has a new class VirtualKeyboard which acts as the focus object and the "proxy" for input methods. The QPA plugin ensures that this is the focusObject, so that all input method related events are sent to this class. From there it will be possible to delegate to other applications through the Wayland interfaces. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1638
2016-04-29 13:05:03 +00:00
QPlatformInputContext *inputContext() const override;
[wayland] Add a QPA plugin for kwin_wayland This introduces an own QPA plugin for KWin. QtWayland's plugin is not a good solution for KWin as QtWayland is meant for Wayland clients and not for a Wayland server. Given that it makes more sense to have a very minimal QPA plugin which supports the use cases we actually have. With our own QPA plugin we should be able to improve the following areas: * no need to create Wayland server before QApplication * Qt::BypassWindowManagerHint can be supported * no workaround for creating OpenGL context in main thread * sharing OpenGL context with Qt * OpenGL context for Qt on libhybris backend The plugin supports so far the following features: * creating a QPlatformWindow using KWayland::Client (ShellSurface) * creating a QPlatformBackingStore using a ShmPool * creating a QPlatformOpenGLContext with Wayland::EGL * or creating a QPlatformOpenGLContext which shares with KWin's scene * creating a QPlatformScreen for each KWayland::Client::Output * QPlatformNativeInterface compatible to QtWayland
2015-08-14 14:52:40 +00:00
Port QPA away from Wayland Summary: So far wayland was used by internal clients to submit raster buffers and position themselves on the screen. While we didn't have issues with submitting raster buffers, there were some problems with positioning task switchers. Mostly, because we had effectively two paths that may alter geometry. A better approach to deal with internal clients is to let our QPA use kwin core api directly. This way we can eliminate unnecessary roundtrips as well make geometry handling much easier and comprehensible. The last missing piece is shadows. Both Plasma::Dialog and Breeze widget style use platform-specific APIs to set and unset shadows. We need to add shadows API to KWindowSystem. Even though some internal clients lack drop-shadows at the moment, I don't consider it to be a blocker. We can add shadows back later on. CCBUG: 386304 Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kwin Tags: #kwin Maniphest Tasks: T9600 Differential Revision: https://phabricator.kde.org/D22810
2019-08-26 07:44:04 +00:00
void initialize() override;
[wayland] Add a QPA plugin for kwin_wayland This introduces an own QPA plugin for KWin. QtWayland's plugin is not a good solution for KWin as QtWayland is meant for Wayland clients and not for a Wayland server. Given that it makes more sense to have a very minimal QPA plugin which supports the use cases we actually have. With our own QPA plugin we should be able to improve the following areas: * no need to create Wayland server before QApplication * Qt::BypassWindowManagerHint can be supported * no workaround for creating OpenGL context in main thread * sharing OpenGL context with Qt * OpenGL context for Qt on libhybris backend The plugin supports so far the following features: * creating a QPlatformWindow using KWayland::Client (ShellSurface) * creating a QPlatformBackingStore using a ShmPool * creating a QPlatformOpenGLContext with Wayland::EGL * or creating a QPlatformOpenGLContext which shares with KWin's scene * creating a QPlatformScreen for each KWayland::Client::Output * QPlatformNativeInterface compatible to QtWayland
2015-08-14 14:52:40 +00:00
private:
[QPA] Implement Screen on top of internal Screens API Summary: The test DontCrashUseractionsMenu (Waylandonly) found an issue in our screen handling implementation in the QPA. The code exposed a short time frame between the dummy screen getting destroyed and the first screen being added. This could result in a crash of KWin. There is actually no need to implement Screen on top of Wayland screen. KWin has all the knowledge, so we can also base this on top of the Screens API. Advantages: * no delays due to Wayland roundtrips * handle screen getting removed (was a TODO) * handle resolution changes (was a TODO) The new implementation has a disadvantage that it destroys and readds all screens whenever something around the screen changes. This shouldn't be an issue in practice as it's only for the internal QPA and thus only affects KWin internal windows which is placed in global coordinates anyway. If it turns out to be a problem we need to track better the screen changes - so far those were not tracked at all. Test Plan: Run a few unit tests which change screens Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D8345
2017-10-17 17:13:50 +00:00
void initScreens();
[wayland] Add a QPA plugin for kwin_wayland This introduces an own QPA plugin for KWin. QtWayland's plugin is not a good solution for KWin as QtWayland is meant for Wayland clients and not for a Wayland server. Given that it makes more sense to have a very minimal QPA plugin which supports the use cases we actually have. With our own QPA plugin we should be able to improve the following areas: * no need to create Wayland server before QApplication * Qt::BypassWindowManagerHint can be supported * no workaround for creating OpenGL context in main thread * sharing OpenGL context with Qt * OpenGL context for Qt on libhybris backend The plugin supports so far the following features: * creating a QPlatformWindow using KWayland::Client (ShellSurface) * creating a QPlatformBackingStore using a ShmPool * creating a QPlatformOpenGLContext with Wayland::EGL * or creating a QPlatformOpenGLContext which shares with KWin's scene * creating a QPlatformScreen for each KWayland::Client::Output * QPlatformNativeInterface compatible to QtWayland
2015-08-14 14:52:40 +00:00
Make sure we don't leak the QPlatformFontDatabase using smart pointers Found it when running KWin on ASAN
2020-07-27 17:53:08 +00:00
QScopedPointer<QPlatformFontDatabase> m_fontDb;
[wayland] Add a QPA plugin for kwin_wayland This introduces an own QPA plugin for KWin. QtWayland's plugin is not a good solution for KWin as QtWayland is meant for Wayland clients and not for a Wayland server. Given that it makes more sense to have a very minimal QPA plugin which supports the use cases we actually have. With our own QPA plugin we should be able to improve the following areas: * no need to create Wayland server before QApplication * Qt::BypassWindowManagerHint can be supported * no workaround for creating OpenGL context in main thread * sharing OpenGL context with Qt * OpenGL context for Qt on libhybris backend The plugin supports so far the following features: * creating a QPlatformWindow using KWayland::Client (ShellSurface) * creating a QPlatformBackingStore using a ShmPool * creating a QPlatformOpenGLContext with Wayland::EGL * or creating a QPlatformOpenGLContext which shares with KWin's scene * creating a QPlatformScreen for each KWayland::Client::Output * QPlatformNativeInterface compatible to QtWayland
2015-08-14 14:52:40 +00:00
QPlatformNativeInterface *m_nativeInterface;
[plugins/qpa] Add a dummy screen on startup Qt has problems initializing everything correctly if there is no screen at startup. E.g. the breeze widget style tries to initialize some pixmaps and this fails. In worst case hitting asserts in Qt (debug build). This change creates a dummy screen which gets destroyed as soon as there is a real screen. Reviewed-By: notmart and sebas
2016-03-10 16:02:06 +00:00
Screen *m_dummyScreen = nullptr;
Integrate QtVirtualKeyboard into KWin/Wayland Summary: The idea is to have KWin provide a virtual keyboard. To support this KWin uses the QT_IM_MODULE qtvirtualkeyboard and makes sure that the QPA plugin loads it. KWin has a new class VirtualKeyboard which acts as the focus object and the "proxy" for input methods. The QPA plugin ensures that this is the focusObject, so that all input method related events are sent to this class. From there it will be possible to delegate to other applications through the Wayland interfaces. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1638
2016-04-29 13:05:03 +00:00
QScopedPointer<QPlatformInputContext> m_inputContext;
[QPA] Implement Screen on top of internal Screens API Summary: The test DontCrashUseractionsMenu (Waylandonly) found an issue in our screen handling implementation in the QPA. The code exposed a short time frame between the dummy screen getting destroyed and the first screen being added. This could result in a crash of KWin. There is actually no need to implement Screen on top of Wayland screen. KWin has all the knowledge, so we can also base this on top of the Screens API. Advantages: * no delays due to Wayland roundtrips * handle screen getting removed (was a TODO) * handle resolution changes (was a TODO) The new implementation has a disadvantage that it destroys and readds all screens whenever something around the screen changes. This shouldn't be an issue in practice as it's only for the internal QPA and thus only affects KWin internal windows which is placed in global coordinates anyway. If it turns out to be a problem we need to track better the screen changes - so far those were not tracked at all. Test Plan: Run a few unit tests which change screens Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D8345
2017-10-17 17:13:50 +00:00
QVector<Screen*> m_screens;
[wayland] Add a QPA plugin for kwin_wayland This introduces an own QPA plugin for KWin. QtWayland's plugin is not a good solution for KWin as QtWayland is meant for Wayland clients and not for a Wayland server. Given that it makes more sense to have a very minimal QPA plugin which supports the use cases we actually have. With our own QPA plugin we should be able to improve the following areas: * no need to create Wayland server before QApplication * Qt::BypassWindowManagerHint can be supported * no workaround for creating OpenGL context in main thread * sharing OpenGL context with Qt * OpenGL context for Qt on libhybris backend The plugin supports so far the following features: * creating a QPlatformWindow using KWayland::Client (ShellSurface) * creating a QPlatformBackingStore using a ShmPool * creating a QPlatformOpenGLContext with Wayland::EGL * or creating a QPlatformOpenGLContext which shares with KWin's scene * creating a QPlatformScreen for each KWayland::Client::Output * QPlatformNativeInterface compatible to QtWayland
2015-08-14 14:52:40 +00:00
};
}
}
#endif
Reference in a new issue Copy permalink