Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) OS: Linux OpenGL is not correctly detected for the Test GL Applet 2 and blue marble applets. The following console output is produced: QGLPixelBuffer: Unable to find a context/format match - giving up. The above code is caused by code in glapplet.cpp. Test GL Applet 2 fails in paintInterface(). bluemarble fails in BlueMarble::initializeGL(). The OpenGL version string is empty in initGL() in kwinglutils.cpp in the bluemarble source directory. bluemarble should have detected that OpenGL could not be initialized instead of using the "shader not supported" message. In any case, something is wrong in glapplet.cpp, at least on my machine. My system uses the proprietary fglrx driver from ATI. glxinfo reports that direct rendering is in use and shaders are supported (I checked everything needed in kwinglutils.cpp). KDE was installed following the instructions in techbase (as a separate user). Sample GL applet works and other OpenGL features work (for KWin).
zack: could you comment on this when you get a chance? thanks.
Same problem here (using fglrx). Its the QGLPixelBuffer that has problems.
Just a little addon note: QGLPixelBuffer::hasOpenGLPbuffer() return false here (fglrx). This should probably be checked in GLApplet::Private::init() ?
The code all those examples (assuming bluemarble just uses glapplet and doesn't do anything stupid) is exactly the same so if one of them just works the others should as well. Having said that, the number and size of supported pbuffers is implementation dependent. We're using pbuffers inside glapplet because the only Qt paintdevices which are capable of creating hardware accelerated GL contexts are qglwidget and qglpixelbuffer. In future Plasma/Qt should have the ability to create a GL context per-executable. This way every applet wouldn't have to create it's own qglpixelbuffer (which are very heavy-weight objects) and be able to use qglframebufferobject. I'm assuming fglrx has either - a nasty bug in pbuffers related code, - a really low limitation on the number of created pbuffers, - fglrx ships with its own libglx and users are mixing it with the stock distro libglx causing those weird mishaps. The bottom line is that the fact that this is with proprietary drivers makes it an uninteresting problem to be honest. The below attached patch should at least make it more consistant in its behavior, feel free to do whatever you want with it
Created attachment 22428 [details] extend the checks and make sure the other constructor uses them as well
Exactly the Problem here. Using the free Radeon Driver on a Ati X800. I dont think it is a fglrx problem. Sadly i cant post a console output cause i don't know how to start plasmoids by Konsole. Maybe somebody could tell me how to do it.
What is "Exactly the Problem here"? Test GL Applet 2 doesn't work and Test GL Applet works? If they both don't work then that's the correct behavior. The Open Source drivers don't have real support for accelerating pbuffers.
Yes the Test GL Applet works. And the Test GL Applet 2 and blue marble don't work. But if the the open source drivers don't have support for accelerating pbuffers i can live without GL Applets. Just thought it is a plasma bug.
Even after applying the patch, the plasmoids behavior is unchanged. Sample GL applet _still_ works. I find it odd and I haven't been able to isolate the cause. Strangely enough, I have also tried linking against the mesa libGL with no change in results. I have verified that both Sample GL Applet and Test GL Applet 2 link against the same libraries. If it's not limited to the fglrx drivers, we probably need to place a note to ATI card users that GL applets are not expected to work with their cards. fgl_glxgears runs fine alongside the sample GL applet, so I'm guessing it's a "only a limited number of pbuffers are allowed" problem with fglrx. I'll try recompiling Qt instead of using the stock Qt 4 provided with Gutsy to see if there is any difference. Is there any chance this could be a Qt bug instead?
so things are doing exactly what they are expected to do given the limitations of drivers .. this is not a bug in plasma and the checks have been made a bit more rigorous. closing.