| Summary: | some full-screen egl apps crashes/hangs on start: QEglContext::swapBuffers(): "Bad surface (0x300D)" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Bernd Grubert <bgrubert> |
| Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | aklhfex, mattst88, sci-astronomy |
| Priority: | Normal | ||
| Version: | autobuilds | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
stellarium log file
EGL_PLATFORM=drm LIBGL_DEBUG=verbose eglinfo EGL_PLATFORM=x11 LIBGL_DEBUG=verbose eglinfo output of apitrace trace stellarium -o stellarium.trace iwth xz compression |
||
|
Description
Bernd Grubert
2012-10-18 20:30:51 UTC
'emerge -1pv qt-gui qt-opengl', if you don't mind (In reply to comment #1) > 'emerge -1pv qt-gui qt-opengl', if you don't mind Here is the output of emerge -1pv qt-gui qt-opengl: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-libs/qt-gui-4.8.2 USE="accessibility cups dbus egl exceptions gif glib mng qt3support tiff xv (-aqua) (-c++0x) -debug -gtkstyle -nas -nis -pch (-qpa) -trace -xinerama" 0 kB [ebuild R ] x11-libs/qt-opengl-4.8.2 USE="egl exceptions qt3support (-aqua) (-c++0x) -debug -pch (-qpa)" 0 kB Total: 2 packages (2 reinstalls), Size of downloads: 0 kB I don't think this is a stellarium bug so much as a intel video bug. My question was not as random as it would seem. I've just had a similar problem with doomsday 1.9.9 (not in portage yet, but neither is quake2-yamagi, so whatever). The solution was 'qt-gui[-egl] qt-opengl[-egl]. There is a slight problem with qt configure script, that this useflag effectively turns into sort of automagical (missing) dependency. The script autodetects 'OpenGL support ......... yes (Desktop OpenGL)' but if egl is passed, it sets qt-opengl to use egl, while in natural detection full screen egl requires OpenGl ES, which would be detected as 'OpenGL support ......... yes (OpenGL ES 2.x)'. The solution is most likely to pass '-opengl desktop' instead of '-opengl' for [-egl] and '-opengl es2' for [egl] (and adjust virtual/opengl dep accordingly). (In reply to comment #4) It's gles that requires egl, not the other way around. Desktop opengl + egl is a valid combination, at least according to the configure script, although discouraged because of bug 405989. Maybe we should just mask the egl USE flag... (In reply to comment #5) > (In reply to comment #4) > > It's gles that requires egl, not the other way around. > > Desktop opengl + egl is a valid combination, at least according to the > configure script, although discouraged because of bug 405989. Maybe we > should just mask the egl USE flag... Well, that configure script is a bit hard to read, but I suspect the issue here is that doomsday is a fullscreen app (is stellarium one too ?) and that might just change the equation a bit. (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > > It's gles that requires egl, not the other way around. > > > > Desktop opengl + egl is a valid combination, at least according to the > > configure script, although discouraged because of bug 405989. Maybe we > > should just mask the egl USE flag... > > Well, that configure script is a bit hard to read, but I suspect the issue > here is that doomsday is a fullscreen app (is stellarium one too ?) and that > might just change the equation a bit. So what's the configuration that works for you? @comment 7: TBH, I'm just guessing here, as I simply rebuilt gui and opengl with [-egl] and on my x86 machine building those two takes a bit too long for to be willing to test my guess, especially that I don't think I actually needed egl support in qt. However, I think certain portions on the script suggest the above as a correct solution.Though perhaps it would be a good idea to ask upstream to clarify what *they* except, as I can't quite find any docs talking about it. OK, on further note: I've been playing with mesa-demos (those from git), mostly with eglinfo, eglgears_screen, eglgears_x11 and eglkms. I can't get eglkms to work - perhaps it's a permission problem (so let's skip it). eglgears_x11 works, but eglgears_screen fails with 'EGLUT: failed to choose a config' - that's probably due to eglChooseConfig returning 0 configs. TBH, I don't know enough about EGL to tell why. (In reply to comment #8) > @comment 7: TBH, I'm just guessing here, as I simply rebuilt gui and opengl > with [-egl] and on my x86 machine building those two takes a bit too long > for to be willing to test my guess, especially that I don't think I actually > needed egl support in qt. > However, I think certain portions on the script suggest the above as a > correct solution.Though perhaps it would be a good idea to ask upstream to > clarify what *they* except, as I can't quite find any docs talking about it. > > OK, on further note: I've been playing with mesa-demos (those from git), > mostly with eglinfo, eglgears_screen, eglgears_x11 and eglkms. > I can't get eglkms to work - perhaps it's a permission problem (so let's > skip it). > eglgears_x11 works, but eglgears_screen fails with 'EGLUT: failed to choose > a config' - that's probably due to eglChooseConfig returning 0 configs. TBH, > I don't know enough about EGL to tell why. I set -egl in the USE variable in make.conf and then emerge -qvauND world emerge --depclean revdep-rebuild After that stellarium works. However, if I understand the description of egl right, I loose some performance, when using OpenGL. But, at least at the moment, I'm fine with the solution. Thanks for your help! Could you capture a trace with dev-util/apitrace and post an xz compressed file showing the problem? Created attachment 327428 [details]
EGL_PLATFORM=drm LIBGL_DEBUG=verbose eglinfo
While not really what was asked for, these two files should shed some light on the problem.
Note, that EGL_PLATFORM=drm needed to be run by root, otherwise the result was:
drm_radeon_getparam_t (RADEON_PARAM_DEVICE_ID): -13
failed to load module: /usr/lib/gbm/gbm_gallium_drm.so: cannot open shared object file: No such file or directory
eglinfo: eglInitialize failed
(on this machine, mesa was [-gallium], so there might be a problem with the ebuid/build system)
Among a few differences, one seems to stand out: for drm only supported surfaces are windows, for x11 the list is longer.
Created attachment 327430 [details]
EGL_PLATFORM=x11 LIBGL_DEBUG=verbose eglinfo
Does prefixing EGL_PLATFORM=x11 on the stellarium invocation fix the problem? Created attachment 327490 [details]
output of apitrace trace stellarium -o stellarium.trace iwth xz compression
(In reply to comment #14) > Created attachment 327490 [details] > output of apitrace trace stellarium -o stellarium.trace iwth xz compression Does this trace replay anything for you? For me $ ./eglretrace ~/Desktop/stellarium.trace 6 glClearColor(red = 0, green = 0, blue = 0, alpha = 1) 6: warning: no current context warning: ignoring call to unavailable function glClearColor error: unavailable function glGetError (I had to build eglretrace from apitrace git, since our ebuild doesn't build it for some reason) re-add me if there's something I need to do with stellarium Please reopen if this is still reproducible on recent versions of qt (4.8.5 or 4.8.6), and also please answer the question in comment #15. |
