On 4/4/18 9:13 PM, qwofford wrote: > I am having trouble launching applications with vglrun from a TurboVNC > session. Server OS is Centos 7. Client OS is OSX. vnc server is > TigerVNC/Xvnc. I followed the server configuration documentation for > VirtualGL 2.5.2, section 6.1 documentation very carefully. I am using > gdm. My configuration answers were YES to restrict 3D X server, YES to> > restrict framebuffer device, and NO to disable XTEST.
You said "TurboVNC session" but then indicated that you were running the TigerVNC Server, which is a different product. I assume you mean that you're using the TigerVNC Server with the TurboVNC Viewer, in which case you're actually running a TigerVNC session (the VNC "session" is on the server.) We generally claim that VirtualGL works with the TigerVNC Server, but The VirtualGL Project hasn't been affiliated with TigerVNC for over five years, so the only kind of support I can offer for it is indirect. I directly support TurboVNC, which is my bread and butter. > My use case involves tunneling port 5950 via SSH with X-forwarding. The > server is launching Xvnc with xinetd/XDMCP. I'm sending xinet logs to > /var/log/messages at maximum verbosity. I don't understand why you would want to do that. That seemingly defeats the purpose of having a virtual X server, i.e. Xvnc. The purpose of such a solution is precisely to avoid sending X11 traffic over the network, which is what you're doing when you use SSH with X11 forwarding. > After xinetd launches Xvnc, xinetd error logs show a peculiar line which > claims a display has been started on screen :0. This confuses me because > my TurboVNC client host is set to "localhost:50" and it connects just > fine. The line in my logs which is suspicious is below: > | > > Apr 419:35:28cn9999 Xvnc[1452]:vncext:VNC extension running! > Apr 419:35:28cn9999 Xvnc[1452]:vncext:created VNC server forscreen 0 > Apr 419:35:28cn9999 Xvnc[1452]:Connections:accepted:127.0.0.1::45176 That really looks as if the TigerVNC Server is loading the TigerVNC X.org module. The TigerVNC X.org module is intended only for single-user remote access to the root display. It's an orthogonal solution to Xvnc and is not intended for use with VirtualGL. > I am then successfully working with the TurboVNC gui (MATE). Section 9.1 > of the VirtualGL 2.5.2 documentation describes my situation precisely: > VirtualGL is running on the same server as my Xvnc server. So I bring up > a terminal and try: > | > $ vglrun glxgears -info > [VGL]ERROR:Couldnotopen display :0. > | > > I wonder if this behavior is related to the suspicious log file above? I > then tried setting the display manually: Did you try the "Sanity Check" procedure described here? https://cdn.rawgit.com/VirtualGL/virtualgl/master/doc/index.html#hd006002 > $ vglrun -display :50glxgears > Runningsynchronizedto the vertical refresh. Theframerate should be > approximately the same asthe monitor refresh rate. > [VGL]ERROR:Couldnotconnect to VGL client. Makesure that vglclient is > [VGL] running andthat either the DISPLAY orVGL_CLIENT environment > [VGL] variable points to the machine on which vglclient isrunning. > [VGL]ERROR:inconnect-- > [VGL] 261:Connectionrefused Not a valid configuration. -display is used to specify the 3D X server, whereas :50 is the 2D X server in your case. You definitely want VGL_DISPLAY/'vglrun -display' to be pointing to :0, which is the default. The problem is that something isn't configured properly vis-a-vis allowing access to :0. > I can establish a connection using vglconnect, but then vglrun simply > uses Mesa instead of my NVIDIA driver> > | > $ vglconnect -display :50-e 'glxgears -info'localhost Also not a valid configuration. vglconnect is used with the VGL Transport, which is only used in conjunction with remote X. It is not used with an X proxy such as Xvnc. > I see the guide at https://virtualgl.org/Documentation/HeadlessNV, and I > have taken these steps. See my steps below: > > | > # lspci | grep NVIDIA > 03:00.0VGA compatible controller:NVIDIA CorporationGK106GL > [QuadroK4000](rev a1) A Quadro K4000 is not headless, and therefore that how-to is not necessary for your hardware. As the User's Guide describes, the basic strategy is to get accelerated OpenGL working on the 3D X server without VirtualGL, then add VirtualGL to the mix. I assume that you can log into Display :0 locally and run 3D applications on the server? If the sanity check procedure fails, then possible causes are: - Incorrect permissions. Did you add your user account to the vglusers group and log out/back in to activate the new group permissions? Note also that you'll probably need to restart the TigerVNC Server session once you've logged back in, in order to pick up the new permissions. - GDM isn't executing /etc/gdm/Init/Default. This is a known bug with the bleeding-edge GDM releases in Fedora, but I'm not aware that it has made it into RHEL yet. To diagnose such things, I insert a line into /etc/gdm/Init/Default that echoes something to a file under /tmp. Upon restarting the 3D X server, I verify whether that file under /tmp has been created. If not, then you might be encountering the bug in question, in which case the only known remedy is to switch to LightDM. If the sanity check procedure succeeds, then I have no idea. XDMCP is not exactly a common configuration these days. -- You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to virtualgl-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/de2ae6de-52e4-b1a6-996f-0c82519ce9da%40virtualgl.org. For more options, visit https://groups.google.com/d/optout.
