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

> 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:

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?


> $ 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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to