This is a workaround fo QTBUG-34898 and affects the VirtualBox driver
and SandyBridge Mobile. OpenGL compositing is just not possible and
crashes as soon as there is anything rendered with QtQuick. This change
should be reverted once the Qt bug is fixed.
To nevertheless use OpenGL one can as always use the KWIN_COMPOSE env
variable, though this will result in crashes. An alternative is to set
QT_OPENGL_NO_SANITY_CHECK which forces Qt into using the threaded
rendering. At least for Sandybridge this seems to be a workable solution
as it's only causing flickering in fullscreen and KWin doesn't use any
fullscreen QtQuick elements.
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.
Instead of looping over every quad for every grid cell and checking
for possible intersections, loop over the quads once and compute
the top left corner of the first intersecting grid cell. Then loop over
all the intersecting cells from that point and create the sub quads.
This new algorithm also preserves the order of the quads in the
original list.
NOBODY should use org.kde.kded5 but instead directly the service
register by its own modulem, but for now let's just switch to .kded5
so we can get this running fast.
Only needs:
* Qt5::DBus for the communication with color correction
* Qt5::X11Extras for access to XCB, pulls in needed Qt5::Gui
* XCB component XCB for xcb calls in kwinglobals.h
It's basically a run of the port-cmake.sh script in here, mostly the changes
are the following:
- Using KF5::* targets
- Using the proper macros, following recent developments in frameworks
As KWin indirectly uses Qt's OpenGL through QtQuick we need to ensure
to not mix OpenGL and OpenGLES. So we have to built KWin only against
OpenGL if Qt is built against OpenGL and we have to built KWin only
against GLESv2 if Qt is built against GLESv2.
This means the kwin_gles binary is no more. There is only kwin which
either links GL or GLESv2.
also work around broken fbo texture clearing on fglrx
so far supports FBO/glClear and resorts to glTexSubImage2D
if the fbo cannot be created or is (in case of fglrx)
known to break, resort to glTexImage2D loading of an
argb array of zeros
BUG: 323065
FIXED-IN: 4.11.2
REVIEW: 112526
Port from kFatal to qFatal - kFatal is still in kde4support,
but lacking debug area support arguably isn't that big a
deal since fatals can't be turned off anyway.
CCMAIL:mgraesslin@kde.org
On GLES, check for OES_texture_3D extension for color correction
Remove a block of ugly hack code that was supposedly needed to build
with OpenGL ES.
Convert the lookup texture data to uint8 on OpenGL ES before sending it
via glTexImage3D, because uint16 is not supported.
Check if the shaders have been reinitialized successfuly when trying to
activate color correction, prevent black screens when there are issues
with the shaders.
BUG: 315419
REVIEW: 111225
(cherry picked from commit 68c68ee3c2b54f968c4d8275f1e8a2e0ccc90dd7)
* "" needs to be wrapped in QStringLiteral
* QString::fromUtf8 needed for const char* and QByteArray
* QByteArray::constData() needed to get to the const char*
Qt 5 only supports raster which means our pixmaps are always non native,
so we don't need the Extension information any more and can drop all
special code handling for mapping a native QPixmap to an X11 pixmap.
