This was a tricky problem to solve, but the good news is that it didn't require interposing all of XCB, and at least in the near term, I don't think that will become a requirement. Referring to http://xcb.freedesktop.org/opengl/ :
"XCB-GLX only communicates with the X server. It does not perform any hardware initialization or touch the OpenGL client-side state. Because of this, XCB-GLX cannot be used as a replacement for the GLX API." Thus, as long as Qt 5 is built with GLX support, it has to use the Xlib-XCB hybrid interface, which means that it will use XCB for 2D stuff and GLX for 3D stuff. That's good news for VirtualGL, because it means that I simply (I say "simply" somewhat ironically, because it was still a tedious job) had to interpose the XCB-GLX functions associated with querying the GLX extension (in order to make Qt 5 believe that GLX exists, even when the 2D X server doesn't support it) and the XCB functions associated with event queue handling (to intercept window resizes.) To wax philosophical, I am frankly not sure why the Qt developers chose to migrate to XCB. There may have been a legitimate reason (performance, perhaps), but after 18 years as a professional developer and 10 years as a professional open source developer, I have noticed a trend recently whereby developers seem to want to change things just for the sake of changing things (systemd, anyone?) and new code seems to be valued more than old, regardless of whether the new code actually represents an improvement for the end user. I see projects re-inventing the whole wheel when just changing one of the spokes would be sufficient, or re-inventing the wheel so it can handle terrain that will only be encountered 1% of the time, or even worse, re-inventing the wheel because of the possibility of encountering terrain that, in reality, will likely never be encountered. When I see this, it doesn't surprise me when I also see large-scale software projects (both open source and proprietary) that have major bugs outstanding for years that are just being ignored. The modern philosophy seems to be, "Who cares about bugs? Let's hack. We can just re-design everything from the ground up, and then all of the old bugs will be gone." Rebuilding the engine instead of changing the oil. At this point, I start shaking my fist at the sky, yelling "Khhhaaaaannnnn", and telling the kids to stop playing on my lawn, etc. XCB can certainly do some things that Xlib can't, but it is undeniably a lower-level and less user-friendly interface-- something that is appropriate as an underlying interface for Xlib but not as a replacement for it. Thus, I'm not really sure why Qt 5 chose to use it. With few applications being written with remote X11 in mind these days, the ability to do asynchronous requests (one of the main selling points of XCB) seems like a pretty weak argument. I'm also noticing that the XCB developers have, over time, allowed some synchronous functions to creep into the API, functions that have 1:1 Xlib equivalents, thus making the argument in favor of XCB even weaker. I would be interested to see a post from the Qt developers regarding why they chose to make the switch, because it isn't obvious to me. At any rate, it wouldn't surprise me if Qt 6 breaks VirtualGL again, or even Qt 5.4.x, but as long as there is no wholesale movement toward using XCB to replace GLX, it should be possible to support these future versions by making incremental modifications to VirtualGL. The new XCB interposer code has been checked into SVN trunk and will be part of the final 2.4 release. Given that XCB is not available on all of the platforms we support, currently this functionality can only be enabled by doing a custom build of VirtualGL and passing -DVGL_FAKEXCB=1 on the CMake command line. I've tested it on CentOS 6, and it should work on systems of similar vintage and newer. Let me know if you run into any issues. On 7/29/14 2:32 AM, DRC wrote: > Ugh. The more I look into this, the nastier it gets. A lot of the > other Qt5 OpenGL demos don't work because VirtualGL isn't intercepting > xcb_glx_query_version(), which the application calls to check whether > the GLX extension is available. But there are other xcb_glx* functions > as well, and it seems like VirtualGL should intercept and reroute those > to avoid future problems. > > I unfortunately don't think that a simple hack is going to be very > meaningful here. It's going to require a full-blown xcb interposer. > Developing this interposer is straightforward, but it's going to be > time-consuming. It will require introducing new hashes solely for the > xcb structures, as well as a new dynamic loader mechanism (since libxcb > isn't available on older platforms, we'll have to check for its presence > before trying to use it.) Extensive testing will be required, which > will probably include porting some of the GLX demos and/or other test > applications in the VirtualGL source to the XCB API. > > This is unfortunately outside of the scope of pro bono work. I will > post it as a hot topic on the web site and see if I can attract funding. > > > On 7/29/14 12:41 AM, peter.ty...@csiro.au wrote: >> An in-house app fails to display any 3D content with VirtualGL since >> it was migrated to Qt5 from Qt4. According to the developer no code >> was changed other than what was required to migrate the app to the Qt5 >> namespace. >> >> -----Original Message----- >> From: DRC [mailto:dcomman...@users.sourceforge.net] >> Sent: Tuesday, 29 July 2014 3:29 PM >> To: virtualgl-users@lists.sourceforge.net >> Subject: Re: [VirtualGL-Users] Issues with Qt 5 >> >> Have you been experiencing other issues besides just the resize issue? >> >> >> On 7/25/14 5:17 AM, peter.ty...@csiro.au wrote: >>> Hi All, >>> >>> We have been having trouble running OpenGL Qt5 apps with VirtualGL >>> including 2.4 beta1. One easily reproducible issue is the OpenGL >>> examples supplied with Qt5 don't resize with their windows when run >>> with VirtualGL. This is seen with both Qt 5.3 we built ourselves and >>> the Qt >>> 5.2 shipped with Ubuntu 14.04 in the qtbase5-examples package. >>> >>> On Ubuntu running the following command and resizing the window >>> produces six lines as per the trace below. Should we see a >>> glXCreatePbuffer call if all is working properly? >>> >>> vglrun +tr /usr/lib/x86_64-linux-gnu/qt5/examples/opengl/cube/cube >>> >>> [VGL] glXMakeCurrent (dpy=0x006c75a0(:1) drawable=0x01400006 >>> ctx=0x0089fed0 config=0x00000135(0x135) drawable=0x01200003 >>> renderer=Quadro K2000/PCIe/SSE2 ) 0.036001 ms >>> >>> [VGL] glXSwapBuffers (dpy=0x006c75a0(:1) drawable=0x01400006 >>> pbw->getglxdrawable()=0x01200003 ) 1.675844 ms >>> >>> [VGL] glXMakeCurrent (dpy=0x006c75a0(:1) drawable=0x01400006 >>> ctx=0x0089fed0 config=0x00000135(0x135) drawable=0x01200003 >>> renderer=Quadro K2000/PCIe/SSE2 ) 0.014782 ms >>> >>> [VGL] glViewport (x=0 y=0 width=737 height=590 ) 0.006914 ms >>> >>> [VGL] glXMakeCurrent (dpy=0x006c75a0(:1) drawable=0x01400006 >>> ctx=0x0089fed0 config=0x00000135(0x135) drawable=0x01200003 >>> renderer=Quadro K2000/PCIe/SSE2 ) 0.010014 ms >>> >>> [VGL] glXSwapBuffers (dpy=0x006c75a0(:1) drawable=0x01400006 >>> pbw->getglxdrawable()=0x01200003 ) 1.435041 ms >>> >>> Regards, >>> >>> Peter >> >> ------------------------------------------------------------------------------ >> >> Infragistics Professional >> Build stunning WinForms apps today! >> Reboot your WinForms applications with our WinForms controls. >> Build a bridge from your legacy apps to the future. >> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> VirtualGL-Users mailing list >> VirtualGL-Users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> >> ------------------------------------------------------------------------------ >> >> Infragistics Professional >> Build stunning WinForms apps today! >> Reboot your WinForms applications with our WinForms controls. >> Build a bridge from your legacy apps to the future. >> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> VirtualGL-Users mailing list >> VirtualGL-Users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> ------------------------------------------------------------------------------ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
