Hmm that's quite strange... the commit mentioned has nothing to do with context creation. I'm slightly leaning towards a "not-our-bug" but I'd appreciate a short test app that I can use to double-check :)

Thanks

I think that commit is a a red herring. 0x3098 is EGL_CONTEXT_CLIENT_VERSION, and Mesa has recently gained more strictness:
         if ((api != EGL_OPENGL_ES_API &&
             (!dpy->Extensions.KHR_create_context || api != EGL_OPENGL_API))) {
               err = EGL_BAD_ATTRIBUTE;
               break;
         }

I suspect QWaylandGLContext is missing eglBindAPI(EGL_OPENGL_ES_API) before context creation.

So, should I report this against qtwayland instead?

Yeah, I would; it seems like Mesa is doing the right thing tbh.

(In reply to Daniel Stone from comment #2)
> I think that commit is a a red herring. 0x3098 is
> EGL_CONTEXT_CLIENT_VERSION, and Mesa has recently gained more strictness:
>          if ((api != EGL_OPENGL_ES_API &&
>              (!dpy->Extensions.KHR_create_context || api !=
> EGL_OPENGL_API))) {
>                err = EGL_BAD_ATTRIBUTE;
>                break;
>          }
> 
> I suspect QWaylandGLContext is missing eglBindAPI(EGL_OPENGL_ES_API) before
> context creation.

Nope, it does call it: http://code.qt.io/cgit/qt/qtwayland.git/tree/src/hardwareintegration/client/wayland-egl/qwaylandglcontext.cpp#n278

I also noticed that i can reproduce this with LIBGL_ALWAYS_SOFTWARE=1, but not when running on i965.

(In reply to Giulio Camuffo from comment #5)
> (In reply to Daniel Stone from comment #2)
> > I think that commit is a a red herring. 0x3098 is
> > EGL_CONTEXT_CLIENT_VERSION, and Mesa has recently gained more strictness:
> >          if ((api != EGL_OPENGL_ES_API &&
> >              (!dpy->Extensions.KHR_create_context || api !=
> > EGL_OPENGL_API))) {
> >                err = EGL_BAD_ATTRIBUTE;
> >                break;
> >          }
> > 
> > I suspect QWaylandGLContext is missing eglBindAPI(EGL_OPENGL_ES_API) before
> > context creation.
> 
> Nope, it does call it:
> http://code.qt.io/cgit/qt/qtwayland.git/tree/src/hardwareintegration/client/
> wayland-egl/qwaylandglcontext.cpp#n278
> 
> I also noticed that i can reproduce this with LIBGL_ALWAYS_SOFTWARE=1, but
> not when running on i965.

If you look at the code more closely you'll see that EGL_CONTEXT_CLIENT_VERSION is set regardless of the API and presence of KHR_create_context. Both of which rather important :)

With that said, I'll repeat my request - please flesh out a simple test app (which does not depend on QT), before we jump on the pointing fingers train :-P

It seems that mesa master's software rendering also causes some problems with SDL v2, and the testgl2 application that is in their repository for Wayland

Reverting Mesa to 10.6 allows this application to work

otherwise I get

libEGL Debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitilize

(In reply to nerdopolis1 from comment #7)
> It seems that mesa master's software rendering also causes some problems
> with SDL v2, and the testgl2 application that is in their repository for
> Wayland
> 
> Reverting Mesa to 10.6 allows this application to work
> 
> otherwise I get
> 
> libEGL Debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitilize

Mind opening up a separate bug, and attaching a test case that does not depend on SDL. Wayland support is not amongst my priority list, so if I have to debug SDL/Qt/etc. I will likely go to near the bottom of my list.

For future reference the qtwayland bug is https://bugreports.qt.io/browse/QTBUG-48166

unfortunately, if I knew how to write a test case...

strictly:~/src/misc/SDL/test% LIBGL_ALWAYS_SOFTWARE=1 ./testgl2
INFO: Screen BPP    : 0
INFO: Swap Interval : 0
INFO: Window Size   : 640,480
INFO: Draw Size     : 640,480
INFO: 
INFO: Vendor        : VMware, Inc.
INFO: Renderer      : Gallium 0.4 on llvmpipe (LLVM 3.7, 256 bits)
INFO: Version       : 3.0 Mesa 11.1.0-devel (git-f4f30ad)
[...]
^CINFO: 189.75 frames per second

Do I need any special configure flags or anything ... ?

(Testing with an ES2-only build of SDL still worked as well, in the sense that both accelerated and software-only gave me a black window and consumed a lot of resources whilst failing to render anything. But initialisation worked fine.)

I compiled SDL master (well default, since it's an HG repo)
./autogen.sh 
./configure --prefix=$INSTALLDIR --libdir=$INSTALLDIR/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH) 


I also ran it under Wayland with
export SDL_VIDEODRIVER=wayland


but it does seem that the SDL issue might have been caused by something later than b2c5986ea1c8e66c4e0a05bcacbcf28c27f5b183, so it could be a separate issue, but I'm not sure what SDL doing to know what to report?

Ugh, so I think I'm using the same options, and I can't see what's going wrong with either big GL or GLES. To be honest, I'm at a total loss ... can you break on _mesa_error when running SDL to see where it's triggered?

(In reply to Daniel Stone from comment #14)
> Ugh, so I think I'm using the same options, and I can't see what's going
> wrong with either big GL or GLES. To be honest, I'm at a total loss ... can
> you break on _mesa_error when running SDL to see where it's triggered?

Doesn't seem that break _mesa_error works, it's not defined...

(In reply to nerdopolis1 from comment #15)
> Doesn't seem that break _mesa_error works, it's not defined...

It should become defined once all the related Mesa libraries get loaded. Looks like 'start' is not enough to pull all shared objects in, the driver needs to load also. Just let it pend "on future shared library load".

Argh, I tried to recompile mesa master with all of the symbols, and now SDL is working, not sure what to think now...

How about 'hooray, it's fixed'? :)

I didn't see any thing in the changelog for 'egl' that looked like it might be a fix... Not 100% sure though

And now all the examples from qtbase/examples/opengl are working as well even after exporting LIBGL_ALWAYS_SOFTWARE as well with mesa master.
including contextinfo, qopenglwidget, qopenglwindow, and threadedqopenglwindow