The hash was completely useless as we never inserted created
FBConfigInfo* into the hash. This change fixes the usage of the
hash and also ensures that it doesn't leak by deleting all hash
elements on tear down.
Current memleak backtrace from ASAN:
Direct leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x4dc932 in operator new(unsigned long) (/home/kfunk/devel/install/kf5/bin/kwin_x11+0x4dc932)
#1 0x7f3c596de0f3 in KWin::GlxBackend::infoForVisual(unsigned int) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:454:12
#2 0x7f3c596e7ef4 in KWin::GlxTexture::loadTexture(unsigned int, QSize const&, unsigned int) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:826:32
#3 0x7f3c596e921e in KWin::GlxTexture::loadTexture(KWin::WindowPixmap*) /home/kfunk/devel/src/kf5/kwin/glxbackend.cpp:869:12
#4 0x7f3c5916e895 in KWin::SceneOpenGL::Texture::load(KWin::WindowPixmap*) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1232:12
#5 0x7f3c5917019a in KWin::OpenGLWindowPixmap::bind() /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1681:20
#6 0x7f3c5916fce0 in KWin::SceneOpenGL::Window::bindTexture() /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1288:12
#7 0x7f3c5917294b in KWin::SceneOpenGL::Window::beginRenderWindow(int, QRegion const&, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1349:10
#8 0x7f3c59176f24 in KWin::SceneOpenGL2Window::performPaint(int, QRegion, KWin::WindowPaintData) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1510:10
#9 0x7f3c5916d410 in KWin::SceneOpenGL2::performPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1161:9
#10 0x7f3c5916cbc9 in KWin::SceneOpenGL2::finalDrawWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1147:9
#11 0x7f3c5922e92f in KWin::EffectsHandlerImpl::drawWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:502:9
#12 0x7f3c590d7bc5 in KWin::Scene::finalPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:606:5
#13 0x7f3c5922c979 in KWin::EffectsHandlerImpl::paintWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:465:9
#14 0x7f3c590d2b38 in KWin::Scene::paintWindow(KWin::Scene::Window*, int, QRegion, KWin::WindowQuadList) /home/kfunk/devel/src/kf5/kwin/scene.cpp:478:5
#15 0x7f3c590ced89 in KWin::Scene::paintSimpleScreen(int, QRegion) /home/kfunk/devel/src/kf5/kwin/scene.cpp:381:9
#16 0x7f3c5916b2b1 in KWin::SceneOpenGL2::paintSimpleScreen(int, QRegion) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:1098:12
#17 0x7f3c590c8bd3 in KWin::Scene::finalPaintScreen(int, QRegion, KWin::ScreenPaintData&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:200:9
#18 0x7f3c5922b062 in KWin::EffectsHandlerImpl::paintScreen(int, QRegion, KWin::ScreenPaintData&) /home/kfunk/devel/src/kf5/kwin/effects.cpp:422:9
#19 0x7f3c590c791f in KWin::Scene::paintScreen(int*, QRegion const&, QRegion const&, QRegion*, QRegion*, QMatrix4x4 const&) /home/kfunk/devel/src/kf5/kwin/scene.cpp:150:5
#20 0x7f3c5915e500 in KWin::SceneOpenGL::paint(QRegion, QList<KWin::Toplevel*>) /home/kfunk/devel/src/kf5/kwin/scene_opengl.cpp:751:9
#21 0x7f3c5907ea3c in KWin::Compositor::performCompositing() /home/kfunk/devel/src/kf5/kwin/composite.cpp:726:29
#22 0x7f3c5907c230 in KWin::Compositor::startupWithWorkspace() /home/kfunk/devel/src/kf5/kwin/composite.cpp:347:5
#23 0x7f3c59079bbb in KWin::Compositor::slotCompositingOptionsInitialized() /home/kfunk/devel/src/kf5/kwin/composite.cpp:283:9
#24 0x7f3c59076084 in KWin::Compositor::setup() /home/kfunk/devel/src/kf5/kwin/composite.cpp:184:9
#25 0x7f3c598b165f in KWin::Compositor::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) /home/kfunk/devel/build/kf5/kwin/moc_composite.cpp:263:18
#26 0x7f3c52de67b0 in QObject::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x2b67b0)
#27 0x7f3c536ab9db in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15b9db)
REVIEW: 127096
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.
and also hint the proper blocking condition (if turning
off swap control)
The detection vars are global, but the swap control requirement
is not preserved, so the detection must re-occur.
Alternatively (and better) the swap control should be saved
and re-applied, but there's trouble on initial detection
CCBUG: 343184
REVIEW: 125659
So far it was bound to whether we build for GLES. But this is
semantically wrong. It might be possible that even on desktop gl
epoxy is built without GLX support, thus we need to reflect this.
This change ensures that epoxy/glx.h is only included if available,
that relevant code is bound to it and that checks are in place to
enforce EGL if not build with glx support.
In addtion the glxbackend.cpp is now only included in the build set
if available.
EglWaylandBackend gains support for creating textures from a
BufferInterface. At the same time it loses the possibility to use
the Xcb shm extension to load the texture. That is Xwayland is
required.
In order to support it in a better way the WindowPixmap is passed
to the Texture for loading and updating. Which is then passed to the
backend specific implementation.
The feature is pretty much untested as it depends on Qt 5.4 and this
was not a requirement during the development of 5.2. On the other hand
regressions in this feature are very severe as it can freeze the screen
and by that render the system unusable.
This change disables the feature by default. To enable it use the
environment variable KWIN_USE_INTEL_SWAP_EVENT=1.
CCBUG: 342582
REVIEW: 122008
The drawable field is set to the X drawable ID when the swap event is
synthesized by DRI2WireToEvent(), and the GLX drawable ID when the
event is received over the wire. The latter being the case with DRI3.
__glXWireToEvent() fixes this for Xlib clients by changing the field
to the X drawable ID. This doesn't work for xcb clients however,
so we have to expect the field to be set to either the X or the GLX
drawable ID.
BUG: 342582
Instead of getting size from displayWidth() and displayHeight() use
the information we have from Screens. This means there is only one
place to have the information and by that we can ensure that all
components use the same data to rely on. displayWidth/displayHeight
seem to provide the wrong information when unplugging an output
without disabling the output. This results in rendering artefacts.
But KWin::Screens has the correct information available.
Not all RGBA 8888 fbconfigs in the NVIDIA driver have an associated
X visual with a 32 bit depth.
This fixes a regression from 88f8078073.
Tested-by: Eike Hein <hein@kde.org>
This adds a SceneOpenGL::Texture::load(..., xcb_visualid_t) overload,
and uses it to bind window pixmaps to textures.
By taking the RGBA masks in the visual into account when choosing an
FBConfig for the GLXPixmap, we are able to disambiguate formats that
have the same depth, such as GL_RGB10_A2 and GL_RGBA8.
It doesn't make sense to convert the extension names to QStrings.
This also replaces the QString parameter in hasGLExtension() with
a QByteArray and adjusts all callers.
Remove the manually written GL dispatch code, and use libepoxy
to resolve functions.
The only exceptions are GLX_MESA_swap_control, which is not in
the XML API registry, and GL_ARB_robustness/GL_EXT_robustness.
For the latter we want to resolve the functions to the same names
on both GLES and desktop GL, and plug in our own implementations
when the extension is not supported.
KWin already has a de facto OpenGL 2 dependency through QML. Combined
with the fact that the OpenGL 1 backend is basically unmaintained and
also unused, it's better to remove it for the new major release.
This change includes:
* Removal of cmake option KWIN_BUILD_OPENGL_1_COMPOSITING
* Removal of KWIN_HAVE_OPENGL_1 compile option and all code
ifdef'ed with it (partially removal of if-else constructs)
* Removal of CompositingType::OpenGL1Compositing (flags are kept
as a core flag should get introduced)
* Driver recommendation for OpenGL1Compositing changed to XRender
(should be evaluated whether the drivers can provide GL2)
* Removal of configuration option "GLLegacy"
* Removal of fooMatrix function in kwinglutils
* Removal of ARBBlurShader
* Removal of legacy code path in GLVertexBuffer
* Removal of GLShaderManager::disable
* if-blocks with ShaderManager::instance()->isValid() removed
REVIEW: 116042
avoiding the blocking swapinterval detection causes
issues in the timing strategy and prevents protection
against CPU overload on the nvidia blob
BUG: 329821
FIXED-IN: 4.11.6
REVIEW: 115306
After losing current from the EGL or GLX
context, calls to the GL or GLES functions
have undefined behavior. Perform all
cleanup that may touch OpenGL and check for
GL errors before losing current from the
context.
REVIEW: 115311
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.
Allow prepareRenderingFrame() to return a region that will be
repainted in addition to the damaged region.
Pass both the damaged region and the repainted region, which
may be larger, as parameters to endRenderingFrame().
With QtQuick2 it's possible that the scene graph rendering context either
lives in an own thread or uses the main GUI thread. In the latter case
it's the same thread as our compositing OpenGL context lives in. This
means our basic assumption that between two rendering passes the context
stays current does not hold.
The code already ensured that before we start a rendering pass the
context is made current, but there are many more possible cases. If we
use OpenGL in areas not triggered by the rendering loop but in response
to other events the context needs to be made current. This includes the
loading and unloading of effects (some effects use OpenGL in the static
effect check, in the ctor and dtor), background loading of texture data,
lazy loading after first usage invoked by shortcut, etc. etc.
To properly handle these cases new methods are added to EffectsHandler
to make the compositing OpenGL context current. These calls delegate down
into the scene. On non-OpenGL scenes they are noop, but on OpenGL they go
into the backend and make the context current. In addition they ensure
that Qt doesn't think that it's QOpenGLContext is current by calling
doneCurrent() on the QOpenGLContext::currentContext(). This unfortunately
causes an additional call to makeCurrent with a null context, but there
is no other way to tell Qt - it doesn't notice when a different context
is made current with low level API calls. In the multi-threaded
architecture this doesn't matter as ::currentContext() returns null.
A short evaluation showed that a transition to QOpenGLContext doesn't
seem feasible. Qt only supports either GLX or EGL while KWin supports
both and when entering the transition phase for Wayland, it would become
extremely tricky if our native platform is X11, but we want a Wayland
EGL context. A future solution might be to have a "KWin-QPA plugin" which
uses either xcb or Wayland and hides everything from Qt.
The API documentation is extended to describe when the effects-framework
ensures that an OpenGL context is current. The effects are changed to
make the context current in cases where it's not guaranteed. This has
been done by looking for creation or deletion of GLTextures and Shaders.
If there are other OpenGL usages outside the rendering loop, ctor/dtor
this needs to be changed, too.
The main purpose of the opengl testapp was to set the environment
variable LIBGL_ALWAYS_INDIRECT if direct rendering is not supported
before glx gets initialized.
With Qt5 we may no longer set this environment variable. QtQuick
requires direct rendering. On IvyBridge QtQuick is crashing if the
variable is set. Thus we are no longer allowed to set it and thus the
complete test becomes pointless.
The test app basically whitelisted most drivers anyway, the only
drivers which were problematic are the proprietary Catalyst drivers.
It that's still a problem we can also disable OpenGL compositing on
those drivers through the recommendation in the GLPlatform.
This also means that the KWIN_DIRECT_GL variable is no longer useful.
With QtQuick2 KWin is no longer the only one having an OpenGL context
thus we need to ensure that our context is current. If not it results in
highly interesting crashes when our code is executed on the QtQuick
context.
The context is made current before we swap and before we start to render
a frame. During rendering a frame it's not made current again based on
the assumption that while we render there is no interference. If this
assumption doesn't hold, we need a more sophisticated solution at the
moment it seems to fix the crashes.
repaints caused by effects so far polluted the timing calculations
since they started the timer on the old vsync offset
This (together with undercut timing) lead to multiple frames in
the buffer queue, and ultimately to a blocking swap
For unsynced painting, it simply caused wrong timings - leading to
"well, kinda around 60Hz - could be 75 as just well".
REVIEW: 112368
CCBUG: 322060
that part is fixed in 4.11.2
