On 16/07/2012 19:54, gunnar.sle...@nokia.com wrote: > On Jul 16, 2012, at 4:54 PM, ext Sean Harmer wrote: > >> On Monday 16 July 2012 07:21:23 Thiago Macieira wrote: >>> On segunda-feira, 16 de julho de 2012 15.12.15, Sean Harmer wrote: >>>> On Monday 16 July 2012 07:08:38 Thiago Macieira wrote: >>>>> I'm asking for Qt 5.0: what should we tell Linux distributors to >>>>> configure >>>>> qtbase with? Considering what requirements qtwayland has, I think it >>>>> needs >>>>> to be -opengl es2. >>>>> >>>>> Correct? >>>> If using wayland then yes I believe so. >>>> >>>> If using xcb backend then -opengl desktop works fine. >>> There's only one build of Qt. The choice is made at compile-time of qtbase, >>> not at run-time like the platform plugin. >>> >>> So everyone should use OpenGL ES 2. >> Unless they want to support applications that use legacy OpenGL calls or >> develop new applications that use modern desktop GL. >> >> There seems to be a dependency issue here that needs resolving. Qtbase itself >> has a configure time switch for OpenGL ES vs Desktop whereas the QPA plugins >> can be decided upon at runtime. Is there some way we can move the GL decision >> to be runtime too I wonder? > We've talked about in the past that Qt could internally resolve all OpenGL > functions and expose proxy functions which at run time are linked towards the > correct library... Incidentally, exactly the problem the patch that started > this thread solves, if it gets expanded to include every extension in the > Khronos registry.
I almost have this aspect completed now. Should be done in the next day or so. Once ready I'll update the patchset. > The reason we didn't go for this in the past is that end-user applications > always link directly against the OpenGL library, so it doesn't matter what > libraries Qt resolves at runtime. The app will resolve a different set of > libraries and the application will be screwed. > > This needs to be solved on the distribution level. It should ship OpenGL ES > or OpenGL, or both in the same library if that is what fits. Yes that would be nice. Hopefully a way forward will present itself soon :) Cheers, Sean -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
