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

65 lines
1.7 KiB
C
Raw Normal View History

Prettify license headers
2020-08-02 22:22:19 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
[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
Prettify license headers
2020-08-02 22:22:19 +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
Prettify license headers
2020-08-02 22:22:19 +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
{
plugins/qpa: Improve handling of output addition and removal With this change, the QPA will try to avoid re-creating all platform screens if a single output has been connected or disconnected.
2020-12-03 19:47:42 +00:00
class AbstractOutput;
[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
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;
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
plugins/qpa: Improve handling of output addition and removal With this change, the QPA will try to avoid re-creating all platform screens if a single output has been connected or disconnected.
2020-12-03 19:47:42 +00:00
private Q_SLOTS:
void handleOutputEnabled(AbstractOutput *output);
void handleOutputDisabled(AbstractOutput *output);
void handlePlatformCreated();
[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
plugins/qpa: Improve handling of output addition and removal With this change, the QPA will try to avoid re-creating all platform screens if a single output has been connected or disconnected.
2020-12-03 19:47:42 +00:00
private:
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: Improve handling of output addition and removal With this change, the QPA will try to avoid re-creating all platform screens if a single output has been connected or disconnected.
2020-12-03 19:47:42 +00:00
QPlatformPlaceholderScreen *m_dummyScreen = nullptr;
QHash<AbstractOutput *, 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