Yes that should still be possible to work. Of course the GLSL shaders: limited sound dangerous and I assume that's where we created a regression.

First step, please try: KWIN_COMPOSE=O2ES kwin_x11 --replace &

If it's related to limited shader support, this will work.

ooc: how do you determine he's on GLES? The config looks quite GLX a-like?

commit 5d416a0f699c68bb15f16c2474d3ba8b615c4d44 seem prone to be the troublemaker

Christoph, does your glxinfo have "GL_ARB_debug_output"?

If not, instead of doing nothing we'll now do something that causes a GL error which is then picked up by the SceneOpenGL2 constructor.

Reverting 5d416a0f does not make a difference. glxinfo says I have "OpenGL extensions: GL_ARB_debug_output".

"KWIN_COMPOSE=O2ES" works with compositing, but it is a lot slower than what I previously had. Switching windows has a delay of about 0.5 seconds. I assume that I used a GLX configuration before.

It looks like I need to git bisect?

Martin seems to already have an idea on the breakage ;-)

If not, you could also enable "libkwinglutils" for logging and should get the GL error that causes the failure printed out (unless it's in journalctl anyway), but I fear that it will be some oversight in the mass patches that turned GLES into a runtime dependency...

# first bad commit: [1d75cd26fb32cca7f88d797f45beee8a6f3ef196] Verify that context is robust before resolving robust functions

Untested, but GL_CONTEXT_FLAGS is afaics introduced in GL 3.0

diff --git a/libkwineffects/kwinglutils_funcs.cpp b/libkwineffects/kwinglutils_funcs.cpp
index df5d755..23a2936 100644
--- a/libkwineffects/kwinglutils_funcs.cpp
+++ b/libkwineffects/kwinglutils_funcs.cpp
@@ -96,9 +96,13 @@ void glResolveFunctions(OpenGLPlatformInterface platformInterface)
         }
     } else {
         if (haveArbRobustness) {
-            GLint value = 0;
-            glGetIntegerv(GL_CONTEXT_FLAGS, &value);
-            if (value & GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT_ARB) {
+            if (hasGLVersion(3, 0)) {
+                GLint value = 0;
+                glGetIntegerv(GL_CONTEXT_FLAGS, &value);
+                if (value & GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT_ARB) {
+                    robustContext = true;
+                }
+            } else {
                 robustContext = true;
             }
         }

Patch from comment #6 works on my system. Thanks Thomas :)

I am a bit surprised that my system has GL_ARB_robustness, but apparently doesn't support GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT_ARB.

The problem is GL_CONTEXT_FLAGS which is only available on GL3.0 while you'll be using GL 2.0
The bit test is local, thus never critical (the symbol is defined and in worst case the bit doesn't match, but the illegal get for GL_CONTEXT_FLAGS will cause an error)

GL_ARB_robustness btw. needs to show up twice in glxinfo (client & server extentions)
In general its fine to add random (inc. custom) extensions to lower GL versions.

@Martin, commit 5d416a0f699c68bb15f16c2474d3ba8b615c4d44 seems to run into the same trap, yesno?

diff --git a/libkwineffects/kwinglutils_funcs.cpp b/libkwineffects/kwinglutils_funcs.cpp
index df5d755..23a2936 100644
--- a/libkwineffects/kwinglutils_funcs.cpp
+++ b/libkwineffects/kwinglutils_funcs.cpp
@@ -96,9 +96,13 @@ void glResolveFunctions(OpenGLPlatformInterface platformInterface)
         }
     } else {
         if (haveArbRobustness) {
-            GLint value = 0;
-            glGetIntegerv(GL_CONTEXT_FLAGS, &value);
-            if (value & GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT_ARB) {
+            if (hasGLVersion(3, 0)) {
+                GLint value = 0;
+                glGetIntegerv(GL_CONTEXT_FLAGS, &value);
+                if (value & GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT_ARB) {
+                    robustContext = true;
+                }
+            } else {
                 robustContext = true;
             }
         }
diff --git a/scene_opengl.cpp b/scene_opengl.cpp
index 955782f..4165998 100644
--- a/scene_opengl.cpp
+++ b/scene_opengl.cpp
@@ -488,8 +488,10 @@ void SceneOpenGL::initDebugOutput()
                 // empirical data shows extension doesn't work
                 return;
             }
+        } else if (!hasGLVersion(3, 0)) {
+            return;
         }
-        // can only be queried with either OpenGL or OpenGL ES of at least 3.1
+        // can only be queried with either OpenGL >= 3.0 or OpenGL ES of at least 3.1
         GLint value = 0;
         glGetIntegerv(GL_CONTEXT_FLAGS, &value);
         if (!(value & GL_CONTEXT_FLAG_DEBUG_BIT)) {

> @Martin, commit 5d416a0f699c68bb15f16c2474d3ba8b615c4d44 seems to run into the same trap

no, becuase it's safe to use the ARB extension, only for the KHR extension it matters. So on a GL system we have the ARB extension and can use it unconditionally anyway. If there is a GL 2 system without ARB, but with the KHR it could hit the problem, too. Which means theoretically yes, practically hopefully no.

My worry is that we have (In reply to Martin Gräßlin from comment #11)
> Which means theoretically yes,  practically *hopefully* no.

The posted patch made that rather safe than sorry ;-)

(A condition I could imagine is a user disabling the ARB extension locally, but "forgets" the KHR one since it's not obviously relevant - or a buggy driver...)

ps: won't be able to push this before noon  (ie. the apparent beta tag), so pleaSe feel free...
notice that i did not even give it a compilation test

Git commit 416d8060cf60ef231e64d1b99b0f40f666953aa2 by Martin Gräßlin.
Committed on 19/11/2015 at 10:20.
Pushed by graesslin into branch 'master'.

Don't query for GL_CONTEXT_FLAGS if not at least OpenGL 3.0

Patch by Thomas Lübking.

M  +7    -3    libkwineffects/kwinglutils_funcs.cpp
M  +3    -1    scene_opengl.cpp

http://commits.kde.org/kwin/416d8060cf60ef231e64d1b99b0f40f666953aa2

Thanks a lot :-)