> These are the assumptions I'm making from the above behavior. > There is an X Server running on machine 1. > When I log into machine 1, it gets attached to my DISPLAY. > When I log into machine 1 through TurboVNC from machine 2, the X Server > is not getting attached to that DISPLAY.
Incorrect. The X server on Machine 1 will *never* get "attached" when you are logging in remotely. What you are probably observing is that, when you log in with SSH, the X11 traffic is forwarded from Machine 1 to Machine 2 through the SSH connection. Thus, on the remote machine, the DISPLAY environment in the SSH session will be set to the remote end of the X11/SSH tunnel, which may be something like localhost:10.0 or whatever. This is *not*, however, pointing to the 3D X server running on Machine 1. In fact, it is pointing to the X server on Machine 2, and when you run an X11 application in that SSH session, the application will send all 2D and 3D rendering over the network through the SSH tunnel, and Machine 2's X server will do the rendering. That isn't what you want, and I refer you to the extensive background article on VirtualGL to explain why. > I realize this is where my wording is falling short. Why doesn't the X > Server get attached to the DISPLAY that is set up by the TurboVNC > vncviewer application? Is this a setting in the TurboVNC > vncviewer/vncserver application? The only reason that 'glxgears' As I said, you need VirtualGL to act as a bridge between the 2D X server and the 3D X server. It appears that you are running VirtualGL correctly in your TurboVNC session, but it isn't working properly on your system for some reason. To help me diagnose why, please run the following on Machine 1's X server and attach the output: /opt/VirtualGL/bin/glxinfo -c /opt/VirtualGL/bin/glreadtest Also specify what version of VirtualGL you are using. If it's not 2.4 beta, please try upgrading to 2.4 beta and see if that fixes the problem. On 9/4/14 2:56 PM, Ladislaus Dombrowski wrote: > Thanks, I appreciate you putting up with me. > > I agree, my wording is very inaccurate. In general, I program > applications on top of systems, but I've been tasked to set up > TurboVNC/virtualgl so here goes. Please forgive me for using incorrect > terms, I'll try my best. > > Machine 1 has TurboVNC and VirtualGL installed. > > Machine 2 has TurboVNC and VirtualGL installed. > > From machine 2, I ssh -X and run 'opt/TurboVNC/bin/vncserver' on > machine 1 (my account) > I write down the number I get from that, let's say '5' > > From machine 2, I run '/opt/TurboVNC/bin/vncviewer' > with the name of machine 1 + the number I received from the ssh command > in this case '5' > > In the TurboVNC desktop that shows up on machine 2, I open a terminal window > Typing 'printenv DISPLAY' yields :2.0 > > I type 'glxgears' and get: > > Xlib: extension "GLX" missing on display ":2.0". > Error: couldn't get and RGB, Double -buffered visual > > I type 'vglrun glxgears' and get: > > Running synchronized to the vertical refresh. The framerate should be > approximately the same as the monitor refresh rate. > [VGL] ERROR: OpenGL error 0x0502 > [VGL] ERROR: in readpixels--- > [VGL] 439: Could not read pixels > > I log on to machine 1 (same user) > I run 'glxgears' > I get a small window with 3 rotating gears > > I run 'vglrun gears' and I get: > > Running synchronized to the vertical refresh. The framerate should be > approximately the same as the monitor refresh rate. > [VGL] ERROR: OpenGL error 0x0502 > [VGL] ERROR: in readpixels--- > [VGL] 439: Could not read pixels > > On machine 1, I ask for the DISPLAY number - 'printenv DISPLAY' > I get :17.0 > > On machine 2, I run 'vglrun glxgears' > I get: > > Running synchronized to the vertical refresh. The framerate should be > approximately the same as the monitor refresh rate. > [VGL] ERROR: OpenGL error 0x0502 > [VGL] ERROR: in readpixels--- > [VGL] 439: Could not read pixels > > > On machine 2, I run 'vglrun -d :17.0 glxgears' > I get a small window with 3 rotating gears > > I log out of machine 1 and the small window with 3 rotating gears goes > away from machine 2 > > On machine 2, I run vglrun glxgears > I get: > > Running synchronized to the vertical refresh. The framerate should be > approximately the same as the monitor refresh rate. > [VGL] ERROR: OpenGL error 0x0502 > [VGL] ERROR: in readpixels--- > [VGL] 439: Could not read pixels > > > These are the assumptions I'm making from the above behavior. > There is an X Server running on machine 1. > When I log into machine 1, it gets attached to my DISPLAY. > When I log into machine 1 through TurboVNC from machine 2, the X Server > is not getting attached to that DISPLAY. > > I realize this is where my wording is falling short. Why doesn't the X > Server get attached to the DISPLAY that is set up by the TurboVNC > vncviewer application? Is this a setting in the TurboVNC > vncviewer/vncserver application? The only reason that 'glxgears' > spinning gears window appears on machine 2 TurboVNC desktop is because > by using '-d :17.0', I'm connecting to the X Server associated with the > DISPLAY number I got from logging into machine 1. When I logged out of > machine 1, the DISPLAY process associated with that login (:17.0) was > killed, hence the 'vglrun -d :17.0 glxgears' process no longer had > anything to connect to. > > Do I have this correct or am I still missing the boat. > > Lad > > > On Thu, Sep 4, 2014 at 2:58 PM, DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>> wrote: > > Your question doesn't make sense, which means that either you aren't > choosing your words correctly or you still don't understand how the > system is supposed to work. What do you mean by "running"? The 3D X > server is completely independent of TurboVNC. They are different X > servers. VirtualGL is the bridge between the two. The 3D X server has > to be running if you are using VirtualGL. It does not have to be > running if you are using TurboVNC without VirtualGL. > > On 9/4/14 11:41 AM, Ladislaus Dombrowski wrote: > > I agree the 3D X server is always running. That was why I was supprised > > that remotely logging in I don't get the 3D X server functionality. I > > only used the -d option to hijack the 3D X server functionality from > > another display. What I can't figure out is why the 3D X server runs > > when you log in directly to the machine, but doesn't run when you log in > > remotely with TurboVNC. > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > > > > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
