Plasma 5.7 cannot find OpenGL

[joaander]

I get the following error when trying to start a Plasma 5.7 session using TurboVNC:

Plasma is unable to start as it could not correctly use OpenGL 2.

I am testing the latest HEAD of master (commit 425fe292d8), and deleted the ~/.vnc/xstartup.turbovnc file to get the new default, as suggested. I am launching turbovncserver from the build directory with: bin/vncserver -3dwm :64. Attached is the log from the Plasma 5.7 startup. The following lines in the log are suspicious, perhaps these are the root cause?

ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

This system is otherwise functioning with both virtualgl and turbovnc. When I set XSESSION=MATE and XSESSION=Xfce and launch the server with bin/vncserver -3dwm :64, I get a functioning desktop. Neither MATE nor Xfce need a 3d window manger, but the LD_PRELOAD is inherited by child processes and I am able to run glxgears using the GPU in the system without needing to manually prefix with vglrun. 3dwm-xinit-vnc-log.txt

[joaander]

Additional requested information:

• This system has 4 NVIDIA GPUs using driver version 367.35
• A Tesla K40 is assigned to VirtualGL
• Error screenshot attached.

[dcommander]

Can you try

sudo chmod u+s /usr/lib64/lib*faker*.so

?? That should at least get rid of the LD_PRELOAD errors. GNOME 3 generates those errors as well, because some of the programs that are run from within the xinit startup scripts are apparently setuid root. GNOME itself isn't setuid root, so the errors in that case are innocuous, and I suspect that they're innocuous here as well, but I've been wrong before.

[joaander]

You are correct. Those errors are innocuous. After setting the files u+s, I get the same error message from plasma - even though the LD_PRELOAD errors are now absent from the log file.

[dcommander]

It might also be worthwhile to try one of our official VirtualGL binary packages, just to make sure there isn't something funky in the Gentoo ebuild. In the past, distributors (specifically Arch) have incorrectly packaged VirtualGL and made it malfunction with applications that use dlopen()/dlsym() to load OpenGL functions.

To extract the RPM or DEB packages under Gentoo: https://www.g-loaded.eu/2008/01/28/how-to-extract-rpm-or-deb-packages/

[joaander]

I unpacked the VirtualGL 2.5 official rpm, set PATH and LD_LIBRARY_PATH appropriately, and KDE Plasma 5.7 loads and functions properly on my system.

I do not think this is the result of a gentoo packaging problem: The latest virtualgl gentoo ebuild is 2.4.1. When I unpacked the official 2.4.1 rpm, I got the same error message.

Conclusion: Plasma 5.7 requires VirtualGL 2.5 (and possibly also the server in TurboVNC master). Thank you very much for your help in getting this working. I will follow up on the mailing list with this solution.

Closing: Not an issue with TurboVNC.

[dcommander]

Cool. That's good info. Now that I know that VGL 2.4.x doesn't work but 2.5 does, I strongly suspect that this is due to XCB. Qt5, upon which Plasma 5.x is based, uses XCB to manage events and query the GLX extension, so VirtualGL has to interpose just enough of the XCB API for that to work. However, VGL 2.4.x didn't enable the XCB interposer by default, because it would have required linking directly with the XCB libraries, thus breaking backward compatibility with older non-XCB-supporting Linux distros. Under VGL 2.4.x, you had to build from source with -DVGL_FAKEXCB=1 and then run the Qt5 application with vglrun +xcb. Since VGL 2.5 has a completely overhauled function loader that can dynamically load functions from the XCB libraries without breaking backward compatibility, the XCB interposer is now enabled by default.

[dcommander]

Updated WM compatibility report (http://www.turbovnc.org/Documentation/Compatibility) to indicate that Plasma 5.7 requires VGL 2.5 or later.