driver bug, there's also no relevant change in kwin between 4.11.2 and 4.11.3
updated mesa or intel-dri?

I have updated mesa from 9.2.1 to 9.2.2 and the intel driver from 2.99.905 to 2.99.905-r1 two days ago.
After the update I logged out of KDE and restarted X. KDE-4.11.2 worked well with OpenGL 3.1.
Yesterday I rebooted and still everything was alright.

The crash happened after the upgrade and apart from KDE nothing got updated today.

Hmm, try adding "XInitThreads();" to the very top of

KDE_EXPORT int kdemain(int argc, char * argv[])
{
   XInitThreads(); // this is the added line
#ifdef M_TRIM_THRESHOLD

in main.cpp (ask if you need patches)

If it keeps crashing, we could only check where "ctx" in bool GlxBackend::initRenderingContext() is actually created and whether eg bypassing the have_robustness branch would change anything.

(In reply to comment #3)
> Hmm, try adding "XInitThreads();" to the very top of
> 
> KDE_EXPORT int kdemain(int argc, char * argv[])
> {
>    XInitThreads(); // this is the added line
> #ifdef M_TRIM_THRESHOLD
> 
> in main.cpp (ask if you need patches)

I did. The crash looks the same in the front frames (assertion), but the trace looks different. (See below.)

> If it keeps crashing, we could only check where "ctx" in bool
> GlxBackend::initRenderingContext() is actually created and whether eg
> bypassing the have_robustness branch would change anything.

How can I test this?

Here is the new backtrace:

Thread 1 (Thread 0x7f81a98ba7c0 (LWP 4868)):
[KCrash Handler]
#6  0x00007f81a9001275 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#7  0x00007f81a90026f8 in __GI_abort () at abort.c:90
#8  0x00007f81a8ffa362 in __assert_fail_base (fmt=0x7f81a975fd5b "%s%s%s:%u: %s%sZusicherung \302\273%s\302\253 nicht erf\303\274llt.\n%n", assertion=assertion@entry=0x7f81a6eea460 "!xcb_xlib_threads_sequence_lost", file=file@entry=0x7f81a6eea3e0 "/var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/xcb_io.c", line=line@entry=274, function=function@entry=0x7f81a6eea828 <__PRETTY_FUNCTION__.14492> "poll_for_event") at assert.c:92
#9  0x00007f81a8ffa412 in __GI___assert_fail (assertion=assertion@entry=0x7f81a6eea460 "!xcb_xlib_threads_sequence_lost", file=file@entry=0x7f81a6eea3e0 "/var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/xcb_io.c", line=line@entry=274, function=function@entry=0x7f81a6eea828 <__PRETTY_FUNCTION__.14492> "poll_for_event") at assert.c:101
#10 0x00007f81a6e798b9 in poll_for_event (dpy=dpy@entry=0x119fde0) at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/xcb_io.c:271
#11 0x00007f81a6e798d1 in poll_for_response (dpy=dpy@entry=0x119fde0) at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/xcb_io.c:289
#12 0x00007f81a6e79e2d in _XEventsQueued (dpy=0x119fde0, mode=mode@entry=1) at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/xcb_io.c:363
#13 0x00007f81a6e79e83 in _XFlush (dpy=<optimized out>) at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/xcb_io.c:514
#14 0x00007f81a6e7caad in _XGetRequest (dpy=0x119fde0, type=type@entry=43 '+', len=len@entry=4) at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/XlibInt.c:1735
#15 0x00007f81a6e7cb9f in _XSeqSyncFunction (dpy=0x119fde0) at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/XlibInt.c:231
#16 0x00007f81a6e7c2ef in _XError (dpy=dpy@entry=0x119fde0, rep=rep@entry=0x7fff9de687a0) at /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/XlibInt.c:1465
#17 0x00007f81a3eeaac2 in __glXSendErrorForXcb (dpy=dpy@entry=0x119fde0, err=err@entry=0x1333ea0) at glx_error.c:83
#18 0x00007f81a3ee6a7d in glXCreateContextAttribsARB (dpy=0x119fde0, config=config@entry=0x13a8d40, share_context=share_context@entry=0x0, direct=direct@entry=1, attrib_list=attrib_list@entry=0x7fff9de68880) at create_context.c:119
#19 0x00007f81a9458c09 in KWin::GlxBackend::initRenderingContext (this=this@entry=0x139fc40) at /home/portage/kde-base/kwin-4.11.3/work/kwin-4.11.3/kwin/glxbackend.cpp:191
#20 0x00007f81a945a06d in KWin::GlxBackend::init (this=0x139fc40) at /home/portage/kde-base/kwin-4.11.3/work/kwin-4.11.3/kwin/glxbackend.cpp:93
#21 0x00007f81a9456c5c in KWin::SceneOpenGL::createScene () at /home/portage/kde-base/kwin-4.11.3/work/kwin-4.11.3/kwin/scene_opengl.cpp:199
#22 0x00007f81a9438a65 in KWin::Compositor::slotCompositingOptionsInitialized (this=0x13635c0) at /home/portage/kde-base/kwin-4.11.3/work/kwin-4.11.3/kwin/composite.cpp:202
#23 0x00007f81a3435c6f in QMetaObject::activate (sender=0x13c05c0, m=<optimized out>, local_signal_index=<optimized out>, argv=0x0) at kernel/qobject.cpp:3547
#24 0x00007f81a3314427 in QFutureWatcherBase::event (this=<optimized out>, event=0x7f81800008c0) at concurrent/qfuturewatcher.cpp:344
#25 0x00007f81a25ba6dc in QApplicationPrivate::notify_helper (this=this@entry=0x119c2d0, receiver=receiver@entry=0x13c05c0, e=e@entry=0x7f81800008c0) at kernel/qapplication.cpp:4562
#26 0x00007f81a25bd05b in QApplication::notify (this=this@entry=0x7fff9de698e0, receiver=receiver@entry=0x13c05c0, e=e@entry=0x7f81800008c0) at kernel/qapplication.cpp:4423
#27 0x00007f81a7d0b076 in KApplication::notify (this=0x7fff9de698e0, receiver=0x13c05c0, event=0x7f81800008c0) at /home/portage/kde-base/kdelibs-4.11.3/work/kdelibs-4.11.3/kdeui/kernel/kapplication.cpp:311
#28 0x00007f81a34217de in QCoreApplication::notifyInternal (this=0x7fff9de698e0, receiver=receiver@entry=0x13c05c0, event=event@entry=0x7f81800008c0) at kernel/qcoreapplication.cpp:949
#29 0x00007f81a3424df1 in sendEvent (event=0x7f81800008c0, receiver=0x13c05c0) at kernel/qcoreapplication.h:231
#30 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x11271f0) at kernel/qcoreapplication.cpp:1573
#31 0x00007f81a3425123 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1466
#32 0x00007f81a265b8c9 in sendPostedEvents () at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:236
#33 QEventDispatcherX11::processEvents (this=0x119c260, flags=...) at kernel/qeventdispatcher_x11.cpp:75
#34 0x00007f81a342047f in QEventLoop::processEvents (this=this@entry=0x7fff9de695e0, flags=...) at kernel/qeventloop.cpp:149
#35 0x00007f81a3420708 in QEventLoop::exec (this=this@entry=0x7fff9de695e0, flags=...) at kernel/qeventloop.cpp:204
#36 0x00007f81a3425958 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1221
#37 0x00007f81a25b904c in QApplication::exec () at kernel/qapplication.cpp:3823
#38 0x00007f81a93effc4 in kdemain (argc=2, argv=0x7fff9de69a28) at /home/portage/kde-base/kwin-4.11.3/work/kwin-4.11.3/kwin/main.cpp:598
#39 0x00007f81a8fed965 in __libc_start_main (main=0x400740 <main(int, char**)>, argc=2, ubp_av=0x7fff9de69a28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff9de69a18) at libc-start.c:258
#40 0x0000000000400771 in _start ()

Created attachment 83493 [details]
context creation debug

See attached patch. it simply prints out what happens during context creation.
My bet is that it will create a non null ctx for teh robust settings and that's gonna be borked.
In case, simply try skipping the robust branch and see what happens.

I have tested you changes. This is the outcome:

With OpenGL 2.0:

========
sed@sed-notebook ~ $ LC_ALL="C"  kwin --replace
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
welcome to KWin context generation, ctx is 0x0 
KWin context generation: have glXCreateContextAttribsARB 
KWin context generation: ctx after robust creation: 0x0 
KWin context generation: ctx after creation: 0xcf5040 
KWin context generation: ctx after glXCreateContextAttribsARB: 0xcf5040 
KWin context generation: activating ctx: 0xcf5040 102761884 
OpenGL vendor string:                   Intel Open Source Technology Center
OpenGL renderer string:                 Mesa DRI Intel(R) Ironlake Mobile 
OpenGL version string:                  2.1 Mesa 9.2.2
OpenGL shading language version string: 1.20
Driver:                                 Intel
GPU class:                              i965
OpenGL version:                         2.1
GLSL version:                           1.20
Mesa version:                           9.2.2
X server version:                       1.14.3
Linux kernel version:                   3.11.7
Direct rendering:                       yes
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes
Virtual Machine:                        no
========

After switching to 3.1:

========

welcome to KWin context generation, ctx is 0x0 
KWin context generation: have glXCreateContextAttribsARB 
KWin context generation: ctx after robust core creation: 0x0 
KWin context generation: ctx after core creation: 0x0 
KWin context generation: ctx after robust creation: 0x0 
KWin context generation: ctx after creation: 0x1a21d20 
KWin context generation: ctx after glXCreateContextAttribsARB: 0x1a21d20 
KWin context generation: activating ctx: 0x1a21d20 96473648 
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
kwin: /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Application::crashHandler() called with signal 6; recent crashes: 1
KCrash: Application 'kwin' crashing...
KCrash: Attempting to start /usr/lib64/kde4/libexec/drkonqi from kdeinit
sock_file=/home/sed/.kde4/socket-sed-notebook/kdeinit4__0
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
kwin(5505): Compositing is not possible 
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread

========

The line "Most likely this is a multi-threaded client and XInitThreads has not been called" caught me, in this compile I did not add the line you suggested to main(). I'll try with that one tomorrow.

> KWin context generation: ctx after core creation: 0x0 
Nice, it doesn't create a GL3 context anyway, but if one tries, that apparently causes an invalid state in the driver.

Please attach the output of "glxinfo"

Created attachment 83513 [details]
glxinfo.txt

This is odd. The glxinfo says "OpenGL version 2.1" (kwin explicitly requests a 2.0 context), but glewinfo returns the following:

========
---------------------------
    GLEW Extension Info
---------------------------

GLEW version 1.10.0
Reporting capabilities of display :0, visual 0x7d
Running on a Mesa DRI Intel(R) Ironlake Mobile  from Intel Open Source Technology Center
OpenGL version 2.1 Mesa 9.2.2 is supported
(...snip...)

GL_VERSION_3_0:                                                OK 
---------------
  glBeginConditionalRender:                                    OK
  glBeginTransformFeedback:                                    OK
  glBindFragDataLocation:                                      OK
  glClampColor:                                                OK
  glClearBufferfi:                                             OK
  glClearBufferfv:                                             OK
  glClearBufferiv:                                             OK
  glClearBufferuiv:                                            OK
  glColorMaski:                                                OK
  glDisablei:                                                  OK
  glEnablei:                                                   OK
  glEndConditionalRender:                                      OK
  glEndTransformFeedback:                                      OK
  glGetBooleani_v:                                             OK
  glGetFragDataLocation:                                       OK
  glGetStringi:                                                OK
  glGetTexParameterIiv:                                        OK
  glGetTexParameterIuiv:                                       OK
  glGetTransformFeedbackVarying:                               OK
  glGetUniformuiv:                                             OK
  glGetVertexAttribIiv:                                        OK
  glGetVertexAttribIuiv:                                       OK
  glIsEnabledi:                                                OK
  glTexParameterIiv:                                           OK
  glTexParameterIuiv:                                          OK
  glTransformFeedbackVaryings:                                 OK
  glUniform1ui:                                                OK
  glUniform1uiv:                                               OK
  glUniform2ui:                                                OK
  glUniform2uiv:                                               OK
  glUniform3ui:                                                OK
  glUniform3uiv:                                               OK
  glUniform4ui:                                                OK
  glUniform4uiv:                                               OK
  glVertexAttribI1i:                                           OK
  glVertexAttribI1iv:                                          OK
  glVertexAttribI1ui:                                          OK
  glVertexAttribI1uiv:                                         OK
  glVertexAttribI2i:                                           OK
  glVertexAttribI2iv:                                          OK
  glVertexAttribI2ui:                                          OK
  glVertexAttribI2uiv:                                         OK
  glVertexAttribI3i:                                           OK
  glVertexAttribI3iv:                                          OK
  glVertexAttribI3ui:                                          OK
  glVertexAttribI3uiv:                                         OK
  glVertexAttribI4bv:                                          OK
  glVertexAttribI4i:                                           OK
  glVertexAttribI4iv:                                          OK
  glVertexAttribI4sv:                                          OK
  glVertexAttribI4ubv:                                         OK
  glVertexAttribI4ui:                                          OK
  glVertexAttribI4uiv:                                         OK
  glVertexAttribI4usv:                                         OK
  glVertexAttribIPointer:                                      OK

GL_VERSION_3_1:                                                OK 
---------------
  glDrawArraysInstanced:                                       OK
  glDrawElementsInstanced:                                     OK
  glPrimitiveRestartIndex:                                     OK
  glTexBuffer:                                                 OK

GL_VERSION_3_2:                                                OK 
---------------
  glFramebufferTexture:                                        OK
  glGetBufferParameteri64v:                                    OK
  glGetInteger64i_v:                                           OK

GL_VERSION_3_3:                                                OK 
---------------
  glVertexAttribDivisor:                                       OK

GL_VERSION_4_0:                                                OK 
---------------
  glBlendEquationSeparatei:                                    OK
  glBlendEquationi:                                            OK
  glBlendFuncSeparatei:                                        OK
  glBlendFunci:                                                OK
  glMinSampleShading:                                          OK

GL_VERSION_4_1:                                                MISSING 
(...snip...)
========

So any version up to OpenGL 4.0 is supported.

(In reply to comment #6)
> The line "Most likely this is a multi-threaded client and XInitThreads has
> not been called" caught me, in this compile I did not add the line you
> suggested to main(). I'll try with that one tomorrow.

I have added XInitThreads() back in and now the debug output is shorter (crashes earlier or different path?)

========

welcome to KWin context generation, ctx is 0x0 
KWin context generation: have glXCreateContextAttribsARB 
KWin context generation: ctx after robust core creation: 0x0 
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
kwin: /var/tmp/portage/x11-libs/libX11-1.6.2/work/libX11-1.6.2/src/xcb_io.c:274: poll_for_event: Zusicherung »!xcb_xlib_threads_sequence_lost« nicht erfüllt.
Application::crashHandler() called with signal 6; recent crashes: 1
KCrash: Application 'kwin' crashing...
KCrash: Attempting to start /usr/lib64/kde4/libexec/drkonqi from kdeinit
sock_file=/home/sed/.kde4/socket-sed-notebook/kdeinit4__0
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
kwin(12243): Compositing is not possible 
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
========

(In reply to comment #8)
> Created attachment 83513 [details]
> glxinfo.txt
> 
> This is odd. The glxinfo says "OpenGL version 2.1" (kwin explicitly requests
> a 2.0 context)

The driver does not annouce core profiles -> no "OpenGL3" compositing (ignore the general OGL3 support)

Afaics (on a glimpse) this does absolutely not permit the driver to crash on utilizing core attributes nevertheless, but we could reasonably simply not try them in this case (as it's gonna fail and cause us trouble)

> [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called

Well, that's not true ;-)

Sum up:
a) still driver bug
b) we could downforce core creation if core profile is not announced instead of relying on NULL return.

*** Bug 321643 has been marked as a duplicate of this bug. ***

*** Bug 324255 has been marked as a duplicate of this bug. ***

*** Bug 327821 has been marked as a duplicate of this bug. ***

*** Bug 328004 has been marked as a duplicate of this bug. ***

(In reply to comment #11)
> *** Bug 321643 has been marked as a duplicate of this bug. ***

I took a look at the bug and one sentence caught my eye:
(In reply to bug #321643 comment #1)
> Does "kwin_gles" work?

I tried it, and kwin_gles works and is set to OpenGL 3.1. What does this mean?

Here is the output:

========
 $ kwin_gles --replace &
[1] 2292
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
OpenGL vendor string:                   Intel Open Source Technology Center
OpenGL renderer string:                 Mesa DRI Intel(R) Ironlake Mobile 
OpenGL version string:                  OpenGL ES 2.0 Mesa 9.2.3
OpenGL shading language version string: OpenGL ES GLSL ES 1.0.16
Driver:                                 Intel
GPU class:                              i965
OpenGL version:                         2.0
GLSL version:                           1.0.16
Mesa version:                           9.2.3
X server version:                       1.14.4
Linux kernel version:                   3.11.9
Direct rendering:                       yes
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes
Virtual Machine:                        no
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
kwin(2292): Failed to compile fragment shader: 
"0:10(36): error: invalid type `sampler3D' in declaration of `u_ccLookupTexture'
0:25(47): error: `u_ccLookupTexture' undeclared
0:0(0): error: no matching function for call to `texture3D(error, vec3)'
0:25(88): error: type mismatch
0:25(104): error: Operands to arithmetic operators must be numeric

kwin(2292): Failed to link shader: 
"error: program lacks a fragment shader

kwin(2292): Shader reinitialization failed, possible compile problems with the shaders altered for color-correction 
========

Yes, Kolor-Manager is enabled. Disabling it makes the errors go away, and the output ends afetr the last "QCoreApplication::sendPostedEvents:" message.


========

*** Bug 328049 has been marked as a duplicate of this bug. ***

> I tried it, and kwin_gles works and is set to OpenGL 3.1. What does this mean?
nothing.

i linked a couple of older bugs at this since, with your kind assistance, we here figured what troubles the driver.
gles is much different from glx and i was asking things to narrow the picture.

If there is anything I could "patch in" into kwin to get more useful output, just drop me a line. ;)

One odd thing just happened. I rebooted, because I had some updates. Nothing special. But when KDE started I expected an immediate crash, because I had kwin_gles running on OpenGL 3.1. Now, of course, glx kwin would start.
The crash didn't happen.
But systemsettings showed "OpenGL 3.1" as being selected.
I switched to OpenGL 2.0, but then clicked on reverting to the previous setting. Everything was working alright, and OpenGL 3.1 was still selected. I then confirmed a change to OpenGL 2.0, changed back to 3.1 and kwin crashed again.

Long story short: Could it be that there is a bug somewhere that shows "OpenGL 3.1" as being selected although it isn't? If this is the case it could be, that, contrary to my initial perception, I hadn't OpenGL 3.1 working and simply was mislead by this non-related bug...

Sounds more like you only get the crash if you 

a) had a GL2 context before and the attempt to create a GL3 one.
or
b) are not on a "cold" system

Run kwin (glx) on OGL2, on a so far not crashed session.

Then

   kreadconfig --file kwinrc --group Compositing --key GLCore

should print "false", next

   kwriteconfig --file kwinrc --group Compositing --key GLCore true

Then

   kwin --replace &

If this crashes, you could try operating on OGL2, changing the value as above and then log out - either just restart X11 (zap or "telinit3" / "telinit 5") or fully reboot (to ensure it's not been a matter of heisenbug)

(In reply to comment #20)
> Run kwin (glx) on OGL2, on a so far not crashed session.
> Then
>    kreadconfig --file kwinrc --group Compositing --key GLCore
> should print "false", next
Yes, this printed "false"

>    kwriteconfig --file kwinrc --group Compositing --key GLCore true
> Then
>    kwin --replace &
This crashed kwin. (As expected, I daresay)

> If this crashes, you could try operating on OGL2, changing the value as
> above and then log out - either just restart X11 (zap or "telinit3" /
> "telinit 5") or fully reboot (to ensure it's not been a matter of heisenbug)
I logged out, restarted xdm/kdm, and logged back in.

SystemSettings state that I am on OpenGL 3.1, and :
 ~ $ kreadconfig --file kwinrc --group Compositing --key GLCore
true

Wow? Now I'd like to know what I can do to have the output of the qDebug() calls I patched into kwin to be written to a file. I'd really like to see where the difference is.

Just for the record:

I rebooted my laptop, ogged back into KDE and attached an external display. The setting still is on OpenGL 3.1 and kreadconfig still prints "true".

(In reply to comment #21)

> Wow? Now I'd like to know what I can do to have the output of the qDebug()
> calls I patched into kwin to be written to a file. I'd really like to see
> where the difference is.

turn "qDebug()" into "kDebug(1212)", run "kdebugdialog --fullmode", filter for 1212, redirect all output to a file of your choice (eg. /tmp/kwin.dbg)

I expect you to see no change. Core profile is not supported and the driver can apparently only handle that before any other context was created.

*** Bug 328847 has been marked as a duplicate of this bug. ***

(In reply to comment #23)
> I expect you to see no change. Core profile is not supported and the driver
> can apparently only handle that before any other context was created.

I found an interesting thread here: https://01.org/linuxgraphics/node/139

Quote:
> Unfortunately, our driver currently only supports GLSL 1.20 on your platform (Ironlake), and
> doesn't support GL_EXT_gpu_shader4 on any platform.  We currently only support 1.30 on
> Sandybridge and later.
>
> Chris Forbes is working on GLSL 1.30 for Ironlake, and is also interested in implementing
> GL_EXT_gpu_shader4, so this may be fixed in the future, but there's no time table for that.

So it seems, that my Pre-Sandybridge Chip isn't new enough for the driver to actually support GLSL 1.30 (OpenGL 3.0 context) or 1.40 (OpenGL 3.1 context).
I guess it is not woth the hassle why, after booting up, the OpenGL3.1 context stands and holds. As soon as I use the keyboard to disable and re-enable the desktop effects, kwin goes bye-bye anyway.

So I am currently staying with 2.0, until the driver catches up.

*** Bug 329075 has been marked as a duplicate of this bug. ***

*** Bug 329334 has been marked as a duplicate of this bug. ***

ftr, i just checked - intel gma945 on mesa 9.1.6 has GLX_ARB_create_context_profile in client and server extensions, so we would really not get around

// create dummy context using legacy call to determine the version
ctx = glXCreateNewContext(display(), fbconfig, GLX_RGBA_TYPE, NULL, direct);
if (ctx) {
   if (glXMakeCurrent(display(), glxWindow, ctx)) {
      QStringList version = QString((const char*)glGetString(GL_VERSION)).section(' ', 0,0).split('.');
      while (version.count() < 2)
         version << "0";
      haveGl3_1 = version.at(0).toInt() >= 3 && version.at(1).toInt() >= 1;
   }
   glXDestroyContext(display(), ctx);
   ctx = 0;
}

just that
a) this seems somehow silly
b) i actually fear that this will even cause more trouble on the affected drivers?

> just that
> a) this seems somehow silly
> b) i actually fear that this will even cause more trouble on the affected
> drivers?
Qt is doing something like that in QtQuick 2. It first creates a dummy context, 
but I think it's wrong(TM), because there is no guarantee that the next 
created context will have the same properties - especially if one changes the 
create attributes, etc.

Anyway I think that a) is a very good reason to do it and of course we don't 
know what will happen for all the drivers out there.

I guess that lacked a "not"?

(In reply to comment #29)
> Anyway I think that a) is a very good reason to [NOT] do it and of course we don't 
                                                                            ^^^^^^^^^^^^^^^^^^^^
> know what will happen for all the drivers out there.

Last resort (in case this remains an issue with future drivers...) could be to extend the exit codes of kwin_opengl_test (which then had to run regardless of the explicit indirect rendering enforcements)
That should at least be less regression prone.

> I guess that lacked a "not"?
yes
> Last resort (in case this remains an issue with future drivers...) could be
> to extend the exit codes of kwin_opengl_test (which then had to run
> regardless of the explicit indirect rendering enforcements)
> That should at least be less regression prone.
we would have to reintroduce the test in master. I dropped it as we may no 
longer use LIBGL_ALWAYS_INDIRECT (breaks Qt)

*** Bug 329908 has been marked as a duplicate of this bug. ***

*** Bug 329984 has been marked as a duplicate of this bug. ***

*** Bug 326352 has been marked as a duplicate of this bug. ***

*** Bug 330440 has been marked as a duplicate of this bug. ***

(In reply to comment #33)  from bug 326352
> testing now r115937

at least with radeon/gallium, this resolved the issue here

*** Bug 332116 has been marked as a duplicate of this bug. ***

*** Bug 333215 has been marked as a duplicate of this bug. ***

bug #328496 has very valuable information and points upstream bug
   https://bugs.freedesktop.org/show_bug.cgi?id=77402
which was apparently fixed by
   http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.15-branch&id=eec04d76a39a7334de4e00ef9f0f6e44c92b3d91

The also kindly provided valgrind log links the bug to this one so I'd suggest to try that patch if you can.

*** Bug 333638 has been marked as a duplicate of this bug. ***

*** Bug 340149 has been marked as a duplicate of this bug. ***

*** Bug 344733 has been marked as a duplicate of this bug. ***