Shouldn't the 3rd step of the fallback kick in if my Direct3D is *not* functional over RDP and I should be left with a software only 3D rendering? Why doesn't that happen? Or did I misunderstand something in your blog post?
Thanks for the explanation about DebugView. I'll check it out. Thanks! Dov On Sat, Jan 24, 2015 at 11:18 PM, Agocs Laszlo < laszlo.ag...@theqtcompany.com> wrote: > Do "set QT_LOGGING_RULES=qt.qpa.gl=true" in the command prompt before > launching the app. Then check the debug output with DebugView. During > application startup a bunch of lines starting with qt.qpa.gl: ... will be > printed. This will tell you which OpenGL implementation is in use. > Alternatively, if using Creator, set the environment variable under the Run > settings. The logs will then show up in the Application Output tab. > > > Real OpenGL is not an option since you will be left with OpenGL 1.1. > ANGLE should work, as long as Direct3D is functional over RDP in your > setup. You might want to try with some Qt examples first. For example > try the Qt Quick examples under qtdeclarative/examples/quick. These all > require OpenGL 2.0. > > > BR, > > Laszlo > > > > ------------------------------ > *From:* development-bounces+laszlo.agocs=theqtcompany....@qt-project.org > <development-bounces+laszlo.agocs=theqtcompany....@qt-project.org> on > behalf of Dov Grobgeld <dov.grobg...@gmail.com> > *Sent:* Saturday, January 24, 2015 5:34 PM > *To:* development@qt-project.org > *Subject:* [Development] > QOpenGLContext::currentContext()->functions()->glCreateShader(GL_VERTEX_SHADER) > returns 0 > > I'm trying to write a cross platform OpenGL application. It is > currently working both on Linux and on Windows when I'm working at the > actual computer, but it fails when trying to run the application under the > remote desktop rdp protocol from Windows to Linux. I traced down the > failure to the fact that: > > QOpenGLContext::currentContext()->functions() > ->glCreateShader(GL_VERTEX_SHADER) > > returns 0, which indicates that the current context was not able to create > a shader. But according to the blog entry at: > > > http://blog.qt.digia.com/blog/2014/11/27/qt-weekly-21-dynamic-opengl-implementation-loading-in-qt-5-4/ > > the following fallback chain should fallback all the way to a software > renderer if no OpenGL or DirectX (through ANGLE) is supported: > > > 1. Try opengl32 and check if OpenGL 2.0 functions are available. > 2. If this fails, try ANGLE. > 3. If initialization fails either due to missing ANGLE libraries or > some other reason, try opengl32sw.dll. In practice this will be a software > rasterizer based implementation. To make it easy to get started, a > pre-built version of Mesa llvmpipe > <http://www.mesa3d.org/llvmpipe.html> is bundled with the binary > packages of Qt 5.4. > > I tried the above program with both the OpenGL and the non-open gl > prebuild Qt-5.4 binary packages, but returned 0 under the remote desktop. > > Am I mistaken to assume that an OpenGL program will work (albeit slow!) > under remote desktop? If not how can I trace down the failure? > > The above blog entry also discusses logging for tracing failures. But > there is no explanation for where this logging is collected, how it is > read, and interpreted. > > Thankful for any help, as it will save me the need to physically access a > windows machine for my Qt OpenGL development! > > Regards, > > Dov > > >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
