Re: [VirtualGL-Users] combine virtualgl and turbovnc

[DRC <dco...@us...>]

You are so far away from the supported configuration and instructions that my only advice is to start over and follow the Users' Guides. vncserver should never be started from .xinitrc. TurboVNC is itself an X server, so it does not depend on the root X server. You indicated previously that you couldn't start TurboVNC any other way, and that is the real problem here. Your inability to start TurboVNC outside of .xinitrc indicates a problem with your system. You didn't provide specifics of how TurboVNC was failing, so I'm not sure what the problem is exactly, but I think you need to back up and figure out how to launch TurboVNC properly first (I can assist if you provide more specific information on how it's failing), then work on configuring VirtualGL.

There are many thousands of VirtualGL and TurboVNC users worldwide who have successfully configured the solutions using the instructions in the users' guides. If there are problems with those instructions, then I'm happy to correct them, but you need to at least try the supported instructions first, and we can work from there.

> On Apr 16, 2017, at 2:01 PM, Steve Volumetric <vol...@gm...> wrote:
> 
> Hello,
> 
> Based on previous advice I've been given from DRC,  I've attempted to start a full X server on display 0, and then launched turbovnc, which starts on display 1
> 
> I did this by launching vncserver from within .xinitrc for a given user that launches X at boot.  This appeared to work, technically it did, but it would recursively launch 100 vnc server sessions, I assume 'vncserver' pulled in .xinitrc and launched it's self.
> 
> now I have one script run at boot:
> 
> su - someuseraccount -c "startx"
> 
> followed immediately by a second script:
> 
> su - someuseraccount -c "vncserver"
> 
> I'm expecting this to start x, which it appears to, I assume it's coming up on display :0, but I'm not sure how to tell for sure remotely
> 
> the second line should simply bring up the vncserver, which appears to be working fine, I can still connect to my system at port 5901 - exactly as before.
> 
> this setup has resolved my issue of the recursive booting with 100 sessions, but now virtual GL doesn't work.
> 
> my GL testing program is Quake3, here is the relevant output:
> 
> ----------------------
> 4487 files in pk3 files
> execing default.cfg
> execing q3config.cfg
> com_zoneMegs will be changed upon restarting.
> couldn't exec autoexec.cfg
> Hunk_Clear: reset the hunk ok
> ----- Client Initialization -----
> Couldn't read q3history.
> ----- Initializing Renderer ----
> Trying to load "renderer_opengl2_x86_64.so" from "."...
> -------------------------------
> QKEY found.
> ----- Client Initialization Complete -----
> ----- R_Init -----
> Invalid MIT-MAGIC-COOKIE-1 keySDL_Init( SDL_INIT_VIDEO ) FAILED (No available video device)
> Invalid MIT-MAGIC-COOKIE-1 keySDL_Init( SDL_INIT_VIDEO ) FAILED (No available video device)
> Setting r_mode -1 failed, falling back on r_mode 3
> Invalid MIT-MAGIC-COOKIE-1 keySDL_Init( SDL_INIT_VIDEO ) FAILED (No available video device)
> ----- Client Shutdown (Client fatal crashed: GLimp_Init() - could not load OpenGL subsystem) -----
> RE_Shutdown( 1 )
> Hunk_Clear: reset the hunk ok
> -----------------------
> GLimp_Init() - could not load OpenGL subsystem
> 
> 
> 
> glxinfo shows:
> Invalid MIT-MAGIC-COOKIE-1 keyError: unable to open display :1
> 
> 
> 
> 
> any advice would be openly welcome.  Thanks in advance.
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users