yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/plugins/platforms/x11/common/eglonxbackend.h

68 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.
Split out the windowing system related part of SceneOpenGL The handling for creating and managing the OpenGL context is split out of the SceneOpenGL into the abstract OpenGLBackend and it's two subclasses GlxBackend and EglOnXBackend. The backends take care of creating the OpenGL context on the windowing system, e.g. on glx an OpenGL context on the overlay window is created and in the egl case an EGL context is created. This means that the SceneOpenGL itself does not have to care about the specific underlying infrastructure. Furthermore the backend provides the Textures for the specific texture from pixmap operations. For that in each of the backend files an additional subclass of the TexturePrivate is defined. These subclasses hold the EglImage and GLXPixmap respectively. The backend is able to create such a private texture and for that the ctor of the Texture is changed to take the backend as a parameter and the Scene provides a factory method for creating Textures. To make this work inside Window the Textures are now hold as pointers which seems a better choice anyway as to the member functions pointers are passed.
2012-08-26 15:14:23 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2012 Martin Gräßlin <mgraesslin@kde.org>
Split out the windowing system related part of SceneOpenGL The handling for creating and managing the OpenGL context is split out of the SceneOpenGL into the abstract OpenGLBackend and it's two subclasses GlxBackend and EglOnXBackend. The backends take care of creating the OpenGL context on the windowing system, e.g. on glx an OpenGL context on the overlay window is created and in the egl case an EGL context is created. This means that the SceneOpenGL itself does not have to care about the specific underlying infrastructure. Furthermore the backend provides the Textures for the specific texture from pixmap operations. For that in each of the backend files an additional subclass of the TexturePrivate is defined. These subclasses hold the EglImage and GLXPixmap respectively. The backend is able to create such a private texture and for that the ctor of the Texture is changed to take the backend as a parameter and the Scene provides a factory method for creating Textures. To make this work inside Window the Textures are now hold as pointers which seems a better choice anyway as to the member functions pointers are passed.
2012-08-26 15:14:23 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
Split out the windowing system related part of SceneOpenGL The handling for creating and managing the OpenGL context is split out of the SceneOpenGL into the abstract OpenGLBackend and it's two subclasses GlxBackend and EglOnXBackend. The backends take care of creating the OpenGL context on the windowing system, e.g. on glx an OpenGL context on the overlay window is created and in the egl case an EGL context is created. This means that the SceneOpenGL itself does not have to care about the specific underlying infrastructure. Furthermore the backend provides the Textures for the specific texture from pixmap operations. For that in each of the backend files an additional subclass of the TexturePrivate is defined. These subclasses hold the EglImage and GLXPixmap respectively. The backend is able to create such a private texture and for that the ctor of the Texture is changed to take the backend as a parameter and the Scene provides a factory method for creating Textures. To make this work inside Window the Textures are now hold as pointers which seems a better choice anyway as to the member functions pointers are passed.
2012-08-26 15:14:23 +00:00
#ifndef KWIN_EGL_ON_X_BACKEND_H
#define KWIN_EGL_ON_X_BACKEND_H
Introduce a shared base class for the EGL backends There's quite some overlap and duplicated code. This AbstractEglBackend tries to merge the two backends a little bit again. This also introduces an AbstractEglTexture which supports both X11 and Wayland "pixmaps" so that EglOnXBackend can support Wayland buffers.
2015-03-19 13:46:39 +00:00
#include "abstract_egl_backend.h"
Move SceneOpenGL into a dedicated plugin Summary: Unfortunately a rather large change which required more refactoring than initially expected. The main problem was that some parts needed to go into platformsupport so that the platform plugins can link them. Due to the rather monolithic nature of scene_opengl.h a few changes were required: * SceneOpenGL::Texture -> SceneOpenGLTexture * SceneOpenGL::TexturePrivate -> SceneOpenGLTexturePrivate * texture based code into dedicated files * SwapProfiler code into dedicated files * SwapProfiler only used in x11 variants * Safety checks for OpenGL scene moved into the new plugin * signal declared in SceneOpenGL moved to Scene, so that we don't need to include SceneOpenGL in composite Test Plan: Nested OpenGL compositor works Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D7740
2017-09-08 20:30:18 +00:00
#include <xcb/xcb.h>
Split out the windowing system related part of SceneOpenGL The handling for creating and managing the OpenGL context is split out of the SceneOpenGL into the abstract OpenGLBackend and it's two subclasses GlxBackend and EglOnXBackend. The backends take care of creating the OpenGL context on the windowing system, e.g. on glx an OpenGL context on the overlay window is created and in the egl case an EGL context is created. This means that the SceneOpenGL itself does not have to care about the specific underlying infrastructure. Furthermore the backend provides the Textures for the specific texture from pixmap operations. For that in each of the backend files an additional subclass of the TexturePrivate is defined. These subclasses hold the EglImage and GLXPixmap respectively. The backend is able to create such a private texture and for that the ctor of the Texture is changed to take the backend as a parameter and the Scene provides a factory method for creating Textures. To make this work inside Window the Textures are now hold as pointers which seems a better choice anyway as to the member functions pointers are passed.
2012-08-26 15:14:23 +00:00
Prepare kwin for compiling with EGL_NO_PLATFORM_SPECIFIC_TYPES
2020-12-10 08:54:14 +00:00
#include <X11/Xlib-xcb.h>
#include <fixx11h.h>
Split out the windowing system related part of SceneOpenGL The handling for creating and managing the OpenGL context is split out of the SceneOpenGL into the abstract OpenGLBackend and it's two subclasses GlxBackend and EglOnXBackend. The backends take care of creating the OpenGL context on the windowing system, e.g. on glx an OpenGL context on the overlay window is created and in the egl case an EGL context is created. This means that the SceneOpenGL itself does not have to care about the specific underlying infrastructure. Furthermore the backend provides the Textures for the specific texture from pixmap operations. For that in each of the backend files an additional subclass of the TexturePrivate is defined. These subclasses hold the EglImage and GLXPixmap respectively. The backend is able to create such a private texture and for that the ctor of the Texture is changed to take the backend as a parameter and the Scene provides a factory method for creating Textures. To make this work inside Window the Textures are now hold as pointers which seems a better choice anyway as to the member functions pointers are passed.
2012-08-26 15:14:23 +00:00
namespace KWin
{
/**
* @brief OpenGL Backend using Egl windowing system over an X overlay window.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +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
class KWIN_EXPORT EglOnXBackend : public AbstractEglBackend
Split out the windowing system related part of SceneOpenGL The handling for creating and managing the OpenGL context is split out of the SceneOpenGL into the abstract OpenGLBackend and it's two subclasses GlxBackend and EglOnXBackend. The backends take care of creating the OpenGL context on the windowing system, e.g. on glx an OpenGL context on the overlay window is created and in the egl case an EGL context is created. This means that the SceneOpenGL itself does not have to care about the specific underlying infrastructure. Furthermore the backend provides the Textures for the specific texture from pixmap operations. For that in each of the backend files an additional subclass of the TexturePrivate is defined. These subclasses hold the EglImage and GLXPixmap respectively. The backend is able to create such a private texture and for that the ctor of the Texture is changed to take the backend as a parameter and the Scene provides a factory method for creating Textures. To make this work inside Window the Textures are now hold as pointers which seems a better choice anyway as to the member functions pointers are passed.
2012-08-26 15:14:23 +00:00
{
public:
Remove KWin::display from kwinglobals Summary: And finally nothing inside libkwineffects, libkwinglutils, libkwinxrenderutils and kwineffect and kwin core uses KWin::display. We are finally XLib free! This change drops KWin::display and removes the include to QX11Info from kwinglobals.h. And the libraries no longer need to link X11Extras. Due to that removal a few seeming unrelated changes are required to add the include where needed and linkage to X11Extras. The biggest change is to x11 platform plugin which still needs the display and caches it in the Platform and passes it to various places in a way that the code doesn't need to be adjusted. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D3337
2016-11-11 08:59:46 +00:00
EglOnXBackend(Display *display);
[wayland] Don't call into X11WindowedBackend from EglOnXBackend Instead of having a ctor which takes the backend, it's a ctor which takes all the information needed from the backend.
2015-05-05 13:35:12 +00:00
explicit EglOnXBackend(xcb_connection_t *connection, Display *display, xcb_window_t rootWindow, int screenNumber, xcb_window_t renderingWindow);
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
~EglOnXBackend() override;
Split Compositor class in Wayland and X11 child classes Summary: This patch is a first take at splitting up of the Compositor class into Wayland and X11 child classes. In this first patch we mostly deal with setup and teardown procedures. A future goal is to further differentiate the compositing part itself too. Test Plan: Manually X from VT and Wayland nested. Autotests pass. Reviewers: #kwin Subscribers: sbergeron, anthonyfieroni, zzag, kwin Tags: #kwin Maniphest Tasks: T11071 Differential Revision: https://phabricator.kde.org/D22195
2019-08-07 17:33:20 +00:00
OverlayWindow* overlayWindow() const override;
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
bool usesOverlayWindow() const override;
Add pure virtual OpenGLBackend::init() method All backends already have an init method so far called from the ctor. This change moves the call to init out of the OpenGL backends and makes it the responsibility of the creating code to also call init on the backend. This change makes it easier to have virtual methods being called during the initialization.
2015-11-25 12:09:28 +00:00
void init() override;
Split out the windowing system related part of SceneOpenGL The handling for creating and managing the OpenGL context is split out of the SceneOpenGL into the abstract OpenGLBackend and it's two subclasses GlxBackend and EglOnXBackend. The backends take care of creating the OpenGL context on the windowing system, e.g. on glx an OpenGL context on the overlay window is created and in the egl case an EGL context is created. This means that the SceneOpenGL itself does not have to care about the specific underlying infrastructure. Furthermore the backend provides the Textures for the specific texture from pixmap operations. For that in each of the backend files an additional subclass of the TexturePrivate is defined. These subclasses hold the EglImage and GLXPixmap respectively. The backend is able to create such a private texture and for that the ctor of the Texture is changed to take the backend as a parameter and the Scene provides a factory method for creating Textures. To make this work inside Window the Textures are now hold as pointers which seems a better choice anyway as to the member functions pointers are passed.
2012-08-26 15:14:23 +00:00
protected:
Refactoring of EglOnXBackend to allow implementing subclasses The aim is to allow having an implementing subclass which uses multiple windows to render to.
2015-11-25 12:32:36 +00:00
virtual bool createSurfaces();
EGLSurface createSurface(xcb_window_t window);
void setHavePlatformBase(bool have) {
m_havePlatformBase = have;
}
bool havePlatformBase() const {
return m_havePlatformBase;
}
platforms/x11: Split out the EGL for X11 backend EGL for X and EGL for Wayland backends are quite different. The main motivation behind this change is to prepare the EGL backends for monitoring vblank events. Things work quite differently depending on if the EGL backend renders onto a toplevel window or overlay window.
2020-11-30 10:27:33 +00:00
bool havePostSubBuffer() const {
return surfaceHasSubPost;
Move the loadTexture for X11 pixmap functionality to the EglOnXBackend Summary: To use eglCreateImageKhr for an X11 pixmap we need an EGLDisplay created for the same XDisplay as the X11 pixmap. This means if we created an EGLDisplay for a GBM device, we are not allowed to load a texture from the X11 pixmap and can result in a crash in the driver. Similar in the nested X11 setup the EGLDisplay is created for the rendering window, but the X11 pixmaps are from the Xwayland server KWin started. They don't belong to the same windowing system. This change addresses this problem by moving the loading of X11 pixmaps from AbstractEglTexture to EglTexture of the EglOnX11Backend. Thus for any usage on a non X11 platform we cannot hit the code path any more. In addition the nested X11 platform can indicate that it doesn't support it and thus also doesn't go through the code path. Test Plan: Tested standalone and nested X11 platform Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D1857
2016-06-14 07:01:42 +00:00
}
platforms/x11: Split out the EGL for X11 backend EGL for X and EGL for Wayland backends are quite different. The main motivation behind this change is to prepare the EGL backends for monitoring vblank events. Things work quite differently depending on if the EGL backend renders onto a toplevel window or overlay window.
2020-11-30 10:27:33 +00:00
bool makeContextCurrent(const EGLSurface &surface);
Move the loadTexture for X11 pixmap functionality to the EglOnXBackend Summary: To use eglCreateImageKhr for an X11 pixmap we need an EGLDisplay created for the same XDisplay as the X11 pixmap. This means if we created an EGLDisplay for a GBM device, we are not allowed to load a texture from the X11 pixmap and can result in a crash in the driver. Similar in the nested X11 setup the EGLDisplay is created for the rendering window, but the X11 pixmaps are from the Xwayland server KWin started. They don't belong to the same windowing system. This change addresses this problem by moving the loading of X11 pixmaps from AbstractEglTexture to EglTexture of the EglOnX11Backend. Thus for any usage on a non X11 platform we cannot hit the code path any more. In addition the nested X11 platform can indicate that it doesn't support it and thus also doesn't go through the code path. Test Plan: Tested standalone and nested X11 platform Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D1857
2016-06-14 07:01:42 +00:00
Split out the windowing system related part of SceneOpenGL The handling for creating and managing the OpenGL context is split out of the SceneOpenGL into the abstract OpenGLBackend and it's two subclasses GlxBackend and EglOnXBackend. The backends take care of creating the OpenGL context on the windowing system, e.g. on glx an OpenGL context on the overlay window is created and in the egl case an EGL context is created. This means that the SceneOpenGL itself does not have to care about the specific underlying infrastructure. Furthermore the backend provides the Textures for the specific texture from pixmap operations. For that in each of the backend files an additional subclass of the TexturePrivate is defined. These subclasses hold the EglImage and GLXPixmap respectively. The backend is able to create such a private texture and for that the ctor of the Texture is changed to take the backend as a parameter and the Scene provides a factory method for creating Textures. To make this work inside Window the Textures are now hold as pointers which seems a better choice anyway as to the member functions pointers are passed.
2012-08-26 15:14:23 +00:00
private:
bool initBufferConfigs();
bool initRenderingContext();
A Scene doesn't need to use an X11 Overlay Window Only the X based Scenes need an overlay window, so the Compositor doesn't need to check for it in the Wayland case. OverlayWindow is moved from OpenGLBackend to the sub classes which need to provide it.
2013-06-19 10:26:34 +00:00
/**
* @brief The OverlayWindow used by this Backend.
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 18:58:33 +00:00
*/
A Scene doesn't need to use an X11 Overlay Window Only the X based Scenes need an overlay window, so the Compositor doesn't need to check for it in the Wayland case. OverlayWindow is moved from OpenGLBackend to the sub classes which need to provide it.
2013-06-19 10:26:34 +00:00
OverlayWindow *m_overlayWindow;
Split out the windowing system related part of SceneOpenGL The handling for creating and managing the OpenGL context is split out of the SceneOpenGL into the abstract OpenGLBackend and it's two subclasses GlxBackend and EglOnXBackend. The backends take care of creating the OpenGL context on the windowing system, e.g. on glx an OpenGL context on the overlay window is created and in the egl case an EGL context is created. This means that the SceneOpenGL itself does not have to care about the specific underlying infrastructure. Furthermore the backend provides the Textures for the specific texture from pixmap operations. For that in each of the backend files an additional subclass of the TexturePrivate is defined. These subclasses hold the EglImage and GLXPixmap respectively. The backend is able to create such a private texture and for that the ctor of the Texture is changed to take the backend as a parameter and the Scene provides a factory method for creating Textures. To make this work inside Window the Textures are now hold as pointers which seems a better choice anyway as to the member functions pointers are passed.
2012-08-26 15:14:23 +00:00
int surfaceHasSubPost;
Allow using EGLOnXBackend with X11WindowedBackend Mostly refactoring to not take the global X11 information (connection, display, etc.). Adds a dedicated ctor overload which takes the X11WindowedBackend. SceneOpenGL is adjusted to create an EGLOnXBackend instead of Wayland one if the X11WindowedBackend is used.
2015-03-19 10:26:53 +00:00
bool m_usesOverlayWindow;
xcb_connection_t *m_connection;
Display *m_x11Display;
xcb_window_t m_rootWindow;
int m_x11ScreenNumber;
[wayland] Don't call into X11WindowedBackend from EglOnXBackend Instead of having a ctor which takes the backend, it's a ctor which takes all the information needed from the backend.
2015-05-05 13:35:12 +00:00
xcb_window_t m_renderingWindow = XCB_WINDOW_NONE;
Refactoring of EglOnXBackend to allow implementing subclasses The aim is to allow having an implementing subclass which uses multiple windows to render to.
2015-11-25 12:32:36 +00:00
bool m_havePlatformBase = false;
Split out the windowing system related part of SceneOpenGL The handling for creating and managing the OpenGL context is split out of the SceneOpenGL into the abstract OpenGLBackend and it's two subclasses GlxBackend and EglOnXBackend. The backends take care of creating the OpenGL context on the windowing system, e.g. on glx an OpenGL context on the overlay window is created and in the egl case an EGL context is created. This means that the SceneOpenGL itself does not have to care about the specific underlying infrastructure. Furthermore the backend provides the Textures for the specific texture from pixmap operations. For that in each of the backend files an additional subclass of the TexturePrivate is defined. These subclasses hold the EglImage and GLXPixmap respectively. The backend is able to create such a private texture and for that the ctor of the Texture is changed to take the backend as a parameter and the Scene provides a factory method for creating Textures. To make this work inside Window the Textures are now hold as pointers which seems a better choice anyway as to the member functions pointers are passed.
2012-08-26 15:14:23 +00:00
};
} // namespace
#endif // KWIN_EGL_ON_X_BACKEND_H
Reference in a new issue Copy permalink