virtualgl-users — VirtualGL User Discussion and Support (moved to Google Groups-- see http://www.VirtualGL.org/About/MailingLists)

[VirtualGL-Users] combine virtualgl and turbovnc

[Steve V. <vol...@gm...>]

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.

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

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

Which version of the RealVNC Viewer were you using?  And on which
platform (Windows, etc.)?  If I can reproduce the failure, then I would
still like to fix it.

On 3/10/17 9:20 AM, Wei Liu wrote:
> I have switched to TurboVNC and has not found any crashes yet. It's a
> great viewer.  So it seems like TurboVNC session does not like my
> realVNC viewer. 
> 
> My compute environment cannot easily build from source...I'm working on
> that and if I"m lucky I can reproduce it with more debugging information. 
> 
> Thanks!
> 
> On Thu, Mar 9, 2017 at 8:25 PM, DRC <dco...@us...
> <mailto:dco...@us...>> wrote:
> 
>     I tried but was unable to reproduce any failure with the RealVNC Viewer.
>      Please provide the information I requested in my previous message.
> 
> 
>     On 2/21/17 4:34 PM, Wei Liu wrote:
>     > Thanks DRC for the information. With all the constraints in our compute
>     > environment, I do want to debug that issue. Here are the log of that
>     > session (may not be helpful), and I will try to follow the debug steps
>     > and put it here.
>     >
>     > //////// crash log ///////////////////////
>     >
>     > /02/2017 14:51:09 Got connection from client 159.70.104.60____
>     >
>     > 21/02/2017 14:51:09   (other clients 159.70.87.121)____
>     >
>     > 21/02/2017 14:51:09 Using protocol version 3.8____
>     >
>     > 21/02/2017 14:51:12 Full-control authentication enabled for
>     > 159.70.104.60____
>     >
>     > 21/02/2017 14:51:12 Enabling full-color cursor updates for client
>     > 159.70.104.60____
>     >
>     > 21/02/2017 14:51:12 rfbProcessClientNormalMessage: ignoring unknown
>     > encoding -223 (ffffff21)____
>     >
>     > 21/02/2017 14:51:12 Using ZRLE encoding for client 159.70.104.60____
>     >
>     > 21/02/2017 14:51:12 rfbProcessClientNormalMessage: ignoring unknown
>     > encoding 15 (f)____
>     >
>     > 21/02/2017 14:51:12 Pixel format for client 159.70.104.60
>     > <http://159.70.104.60/>:____
>     >
>     > 21/02/2017 14:51:12   8 bpp, depth 8____
>     >
>     > 21/02/2017 14:51:12   uses a colour map (not true colour).____
>     >
>     > 21/02/2017 14:51:13 Pixel format for client 159.70.104.60
>     > <http://159.70.104.60/>:____
>     >
>     > 21/02/2017 14:51:13   32 bpp, depth 24, little endian____
>     >
>     > 21/02/2017 14:51:13   true colour: max r 255 g 255 b 255, shift r 16 g 8
>     > b 0____
>     >
>     > 21/02/2017 14:51:13   no translation needed____
>     >
>     > 21/02/2017 14:51:13 Enabling full-color cursor updates for client
>     > 159.70.104.60____
>     >
>     > 21/02/2017 14:51:13 rfbProcessClientNormalMessage: ignoring unknown
>     > encoding -223 (ffffff21)____
>     >
>     > 21/02/2017 14:51:13 Using hextile encoding for client 159.70.104.60____
>     >
>     > 21/02/2017 14:51:13 rfbProcessClientNormalMessage: ignoring unknown
>     > encoding 15 (f)____
>     >
>     > 21/02/2017 15:06:44 rfbProcessClientNormalMessage: read: Connection
>     > timed out____
>     >
>     > 21/02/2017 15:06:44 Client 159.70.87.121 gone____
>     >
>     > 21/02/2017 15:06:44 Statistics:____
>     >
>     > 21/02/2017 15:06:44   key events received 686, pointer events 136033____
>     >
>     > 21/02/2017 15:06:44   framebuffer updates 21954, rectangles 62990, bytes
>     > -171025480____
>     >
>     > 21/02/2017 15:06:44     cursor shape updates 1581, bytes 3577869____
>     >
>     > 21/02/2017 15:06:44     raw rectangles 1, bytes 17292____
>     >
>     > 21/02/2017 15:06:44     copyRect rectangles 1696, bytes 27136____
>     >
>     > 21/02/2017 15:06:44     hextile rectangles 59711, bytes -174662874____
>     >
>     > 21/02/2017 15:06:44____
>     >
>     > (nautilus:80266): Gdk-WARNING **: nautilus: Fatal IO error 11 (Resource
>     > temporarily unavailable) on X server :4.____
>     >
>     > __ __
>     >
>     > __ __
>     >
>     > (gnome-terminal:80262): Gdk-WARNING **: gnome-terminal: Fatal IO error
>     > 11 (Resource temporarily unavailable) on X server :4.____
>     >
>     > __ __
>     >
>     > XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server
>     > ":4"____
>     >
>     > __ __
>     >
>     > (gnome-settings-daemon:80264): Gdk-WARNING **: gnome-settings-daemon:
>     > Fatal IO error 11 (Resource temporarily unavailable) on X server :4.____
>     >
>     > __ __
>     >
>     >       after 120 requests (119 known processed) with 0 events remaining.____
>     >
>     > Window manager warning: Fatal IO error 11 (Resource temporarily
>     > unavailable) on display ':4'.____
>     >
>     > __ __
>     >
>     > (gnome-panel:80263): Gdk-WARNING **: gnome-panel: Fatal IO error 11
>     > (Resource temporarily unavailable) on X server :4.____
>     >
>     >
>     > On Tue, Feb 21, 2017 at 5:25 PM, DRC <dco...@us...
>     <mailto:dco...@us...>
>     > <mailto:dco...@us...
>     <mailto:dco...@us...>>> wrote:
>     >
>     >     Definitely should not be happening.  Since it's likely related to
>     >     TurboVNC, my suggestion would be to build the TurboVNC Server from
>     >     source and include debugging information in the build:
>     >
>     >         sudo apt-get install gcc make git cmake libpam0g-dev libsm-dev
>     >     libice-dev libxext-dev libssl-dev
>     >         git clone https://github.com/TurboVNC/turbovnc.git
>     <https://github.com/TurboVNC/turbovnc.git>
>     >     <https://github.com/TurboVNC/turbovnc.git
>     <https://github.com/TurboVNC/turbovnc.git>>
>     >         cd turbovnc
>     >         mkdir build
>     >         cd build
>     >         cmake -G"Unix Makefiles" -DTVNC_BUILDNATIVE=0 -DTVNC_BUILDJAVA=0
>     >     -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
>     >         make
>     >
>     >     Now launch the server with:
>     >
>     >         ulimit -c 10000000
>     >         bin/vncserver -debug
>     >
>     >     When the server crashes, it should leave a core file.  Load that core
>     >     file into gdb:
>     >
>     >         gdb bin/Xvnc {core file}
>     >
>     >     Type 'where' in gdb to print a stack trace.
>     >
>     >     Create an issue in the TurboVNC GitHub tracker:
>     >     https://github.com/TurboVNC/turbovnc/issues/new
>     <https://github.com/TurboVNC/turbovnc/issues/new>
>     >     <https://github.com/TurboVNC/turbovnc/issues/new
>     <https://github.com/TurboVNC/turbovnc/issues/new>>
>     >
>     >     and post the following:
>     >
>     >         -- The stack trace you obtained above
>     >         -- The console output from the TurboVNC Server
>     >         -- What version of the RealVNC Viewer you were using (example:
>     >     4.1.2)
>     >         -- What client O/S you were using (examples: Windows 7, iOS 9, macOS
>     >     Sierra)
>     >         -- What RFB encoding you were using (examples: Hextile, ZRLE)
>     >
>     >     All of that aside, while it is a bug for the RealVNC Viewer to crash the
>     >     TurboVNC Server, and I definitely want to fix that bug, I also cannot
>     >     recommend using the RealVNC Viewer.  The TurboVNC Viewer will be
>     >     necessary in order to achieve full performance with our server.
>     >
>     >
>     >     On 2/21/17 4:02 PM, Wei Liu wrote:
>     >     > Jason, DRC,
>     >     >
>     >     > The vnc session I created with TurboVNC crashes a few times. Can it be
>     >     > caused by my realVNC viewer? (seems hard to believe an incompatible
>     >     > viewer crashes the session) I haven't got a chance to use TurboVNC
>     >     > viewer due to other constraints.
>     >     >
>     >     > How to debug that crashes? I can put more information if I know how.
>     >     >
>     >     > I did run some OpenGL applications in the session. Not sure if it is
>     >     > related.
>     >     >
>     >     > Thank you very much,
> 
> 
>     ------------------------------------------------------------------------------
>     Announcing the Oxford Dictionaries API! The API offers world-renowned
>     dictionary content that is easy and intuitive to access. Sign up for an
>     account today to start using our lexical data to power your apps and
>     projects. Get started today and enter our developer competition.
>     http://sdm.link/oxford
>     _______________________________________________
>     VirtualGL-Users mailing list
>     Vir...@li...
>     <mailto:Vir...@li...>
>     https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>     <https://lists.sourceforge.net/lists/listinfo/virtualgl-users>
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> 
> 
> 
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> 

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

[Wei L. <wei...@gm...>]

I have switched to TurboVNC and has not found any crashes yet. It's a great
viewer.  So it seems like TurboVNC session does not like my realVNC viewer.

My compute environment cannot easily build from source...I'm working on
that and if I"m lucky I can reproduce it with more debugging information.

Thanks!

On Thu, Mar 9, 2017 at 8:25 PM, DRC <dco...@us...>
wrote:

> I tried but was unable to reproduce any failure with the RealVNC Viewer.
>  Please provide the information I requested in my previous message.
>
>
> On 2/21/17 4:34 PM, Wei Liu wrote:
> > Thanks DRC for the information. With all the constraints in our compute
> > environment, I do want to debug that issue. Here are the log of that
> > session (may not be helpful), and I will try to follow the debug steps
> > and put it here.
> >
> > //////// crash log ///////////////////////
> >
> > /02/2017 14:51:09 Got connection from client 159.70.104.60____
> >
> > 21/02/2017 14:51:09   (other clients 159.70.87.121)____
> >
> > 21/02/2017 14:51:09 Using protocol version 3.8____
> >
> > 21/02/2017 14:51:12 Full-control authentication enabled for
> > 159.70.104.60____
> >
> > 21/02/2017 14:51:12 Enabling full-color cursor updates for client
> > 159.70.104.60____
> >
> > 21/02/2017 14:51:12 rfbProcessClientNormalMessage: ignoring unknown
> > encoding -223 (ffffff21)____
> >
> > 21/02/2017 14:51:12 Using ZRLE encoding for client 159.70.104.60____
> >
> > 21/02/2017 14:51:12 rfbProcessClientNormalMessage: ignoring unknown
> > encoding 15 (f)____
> >
> > 21/02/2017 14:51:12 Pixel format for client 159.70.104.60
> > <http://159.70.104.60/>:____
> >
> > 21/02/2017 14:51:12   8 bpp, depth 8____
> >
> > 21/02/2017 14:51:12   uses a colour map (not true colour).____
> >
> > 21/02/2017 14:51:13 Pixel format for client 159.70.104.60
> > <http://159.70.104.60/>:____
> >
> > 21/02/2017 14:51:13   32 bpp, depth 24, little endian____
> >
> > 21/02/2017 14:51:13   true colour: max r 255 g 255 b 255, shift r 16 g 8
> > b 0____
> >
> > 21/02/2017 14:51:13   no translation needed____
> >
> > 21/02/2017 14:51:13 Enabling full-color cursor updates for client
> > 159.70.104.60____
> >
> > 21/02/2017 14:51:13 rfbProcessClientNormalMessage: ignoring unknown
> > encoding -223 (ffffff21)____
> >
> > 21/02/2017 14:51:13 Using hextile encoding for client 159.70.104.60____
> >
> > 21/02/2017 14:51:13 rfbProcessClientNormalMessage: ignoring unknown
> > encoding 15 (f)____
> >
> > 21/02/2017 15:06:44 rfbProcessClientNormalMessage: read: Connection
> > timed out____
> >
> > 21/02/2017 15:06:44 Client 159.70.87.121 gone____
> >
> > 21/02/2017 15:06:44 Statistics:____
> >
> > 21/02/2017 15:06:44   key events received 686, pointer events 136033____
> >
> > 21/02/2017 15:06:44   framebuffer updates 21954, rectangles 62990, bytes
> > -171025480____
> >
> > 21/02/2017 15:06:44     cursor shape updates 1581, bytes 3577869____
> >
> > 21/02/2017 15:06:44     raw rectangles 1, bytes 17292____
> >
> > 21/02/2017 15:06:44     copyRect rectangles 1696, bytes 27136____
> >
> > 21/02/2017 15:06:44     hextile rectangles 59711, bytes -174662874____
> >
> > 21/02/2017 15:06:44____
> >
> > (nautilus:80266): Gdk-WARNING **: nautilus: Fatal IO error 11 (Resource
> > temporarily unavailable) on X server :4.____
> >
> > __ __
> >
> > __ __
> >
> > (gnome-terminal:80262): Gdk-WARNING **: gnome-terminal: Fatal IO error
> > 11 (Resource temporarily unavailable) on X server :4.____
> >
> > __ __
> >
> > XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server
> > ":4"____
> >
> > __ __
> >
> > (gnome-settings-daemon:80264): Gdk-WARNING **: gnome-settings-daemon:
> > Fatal IO error 11 (Resource temporarily unavailable) on X server :4.____
> >
> > __ __
> >
> >       after 120 requests (119 known processed) with 0 events
> remaining.____
> >
> > Window manager warning: Fatal IO error 11 (Resource temporarily
> > unavailable) on display ':4'.____
> >
> > __ __
> >
> > (gnome-panel:80263): Gdk-WARNING **: gnome-panel: Fatal IO error 11
> > (Resource temporarily unavailable) on X server :4.____
> >
> >
> > On Tue, Feb 21, 2017 at 5:25 PM, DRC <dco...@us...
> > <mailto:dco...@us...>> wrote:
> >
> >     Definitely should not be happening.  Since it's likely related to
> >     TurboVNC, my suggestion would be to build the TurboVNC Server from
> >     source and include debugging information in the build:
> >
> >         sudo apt-get install gcc make git cmake libpam0g-dev libsm-dev
> >     libice-dev libxext-dev libssl-dev
> >         git clone https://github.com/TurboVNC/turbovnc.git
> >     <https://github.com/TurboVNC/turbovnc.git>
> >         cd turbovnc
> >         mkdir build
> >         cd build
> >         cmake -G"Unix Makefiles" -DTVNC_BUILDNATIVE=0 -DTVNC_BUILDJAVA=0
> >     -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
> >         make
> >
> >     Now launch the server with:
> >
> >         ulimit -c 10000000
> >         bin/vncserver -debug
> >
> >     When the server crashes, it should leave a core file.  Load that core
> >     file into gdb:
> >
> >         gdb bin/Xvnc {core file}
> >
> >     Type 'where' in gdb to print a stack trace.
> >
> >     Create an issue in the TurboVNC GitHub tracker:
> >     https://github.com/TurboVNC/turbovnc/issues/new
> >     <https://github.com/TurboVNC/turbovnc/issues/new>
> >
> >     and post the following:
> >
> >         -- The stack trace you obtained above
> >         -- The console output from the TurboVNC Server
> >         -- What version of the RealVNC Viewer you were using (example:
> >     4.1.2)
> >         -- What client O/S you were using (examples: Windows 7, iOS 9,
> macOS
> >     Sierra)
> >         -- What RFB encoding you were using (examples: Hextile, ZRLE)
> >
> >     All of that aside, while it is a bug for the RealVNC Viewer to crash
> the
> >     TurboVNC Server, and I definitely want to fix that bug, I also cannot
> >     recommend using the RealVNC Viewer.  The TurboVNC Viewer will be
> >     necessary in order to achieve full performance with our server.
> >
> >
> >     On 2/21/17 4:02 PM, Wei Liu wrote:
> >     > Jason, DRC,
> >     >
> >     > The vnc session I created with TurboVNC crashes a few times. Can
> it be
> >     > caused by my realVNC viewer? (seems hard to believe an incompatible
> >     > viewer crashes the session) I haven't got a chance to use TurboVNC
> >     > viewer due to other constraints.
> >     >
> >     > How to debug that crashes? I can put more information if I know
> how.
> >     >
> >     > I did run some OpenGL applications in the session. Not sure if it
> is
> >     > related.
> >     >
> >     > Thank you very much,
>
>
> ------------------------------------------------------------
> ------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

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

I tried but was unable to reproduce any failure with the RealVNC Viewer.
 Please provide the information I requested in my previous message.


On 2/21/17 4:34 PM, Wei Liu wrote:
> Thanks DRC for the information. With all the constraints in our compute
> environment, I do want to debug that issue. Here are the log of that
> session (may not be helpful), and I will try to follow the debug steps
> and put it here. 
> 
> //////// crash log ///////////////////////
> 
> /02/2017 14:51:09 Got connection from client 159.70.104.60____
> 
> 21/02/2017 14:51:09   (other clients 159.70.87.121)____
> 
> 21/02/2017 14:51:09 Using protocol version 3.8____
> 
> 21/02/2017 14:51:12 Full-control authentication enabled for
> 159.70.104.60____
> 
> 21/02/2017 14:51:12 Enabling full-color cursor updates for client
> 159.70.104.60____
> 
> 21/02/2017 14:51:12 rfbProcessClientNormalMessage: ignoring unknown
> encoding -223 (ffffff21)____
> 
> 21/02/2017 14:51:12 Using ZRLE encoding for client 159.70.104.60____
> 
> 21/02/2017 14:51:12 rfbProcessClientNormalMessage: ignoring unknown
> encoding 15 (f)____
> 
> 21/02/2017 14:51:12 Pixel format for client 159.70.104.60
> <http://159.70.104.60/>:____
> 
> 21/02/2017 14:51:12   8 bpp, depth 8____
> 
> 21/02/2017 14:51:12   uses a colour map (not true colour).____
> 
> 21/02/2017 14:51:13 Pixel format for client 159.70.104.60
> <http://159.70.104.60/>:____
> 
> 21/02/2017 14:51:13   32 bpp, depth 24, little endian____
> 
> 21/02/2017 14:51:13   true colour: max r 255 g 255 b 255, shift r 16 g 8
> b 0____
> 
> 21/02/2017 14:51:13   no translation needed____
> 
> 21/02/2017 14:51:13 Enabling full-color cursor updates for client
> 159.70.104.60____
> 
> 21/02/2017 14:51:13 rfbProcessClientNormalMessage: ignoring unknown
> encoding -223 (ffffff21)____
> 
> 21/02/2017 14:51:13 Using hextile encoding for client 159.70.104.60____
> 
> 21/02/2017 14:51:13 rfbProcessClientNormalMessage: ignoring unknown
> encoding 15 (f)____
> 
> 21/02/2017 15:06:44 rfbProcessClientNormalMessage: read: Connection
> timed out____
> 
> 21/02/2017 15:06:44 Client 159.70.87.121 gone____
> 
> 21/02/2017 15:06:44 Statistics:____
> 
> 21/02/2017 15:06:44   key events received 686, pointer events 136033____
> 
> 21/02/2017 15:06:44   framebuffer updates 21954, rectangles 62990, bytes
> -171025480____
> 
> 21/02/2017 15:06:44     cursor shape updates 1581, bytes 3577869____
> 
> 21/02/2017 15:06:44     raw rectangles 1, bytes 17292____
> 
> 21/02/2017 15:06:44     copyRect rectangles 1696, bytes 27136____
> 
> 21/02/2017 15:06:44     hextile rectangles 59711, bytes -174662874____
> 
> 21/02/2017 15:06:44____
> 
> (nautilus:80266): Gdk-WARNING **: nautilus: Fatal IO error 11 (Resource
> temporarily unavailable) on X server :4.____
> 
> __ __
> 
> __ __
> 
> (gnome-terminal:80262): Gdk-WARNING **: gnome-terminal: Fatal IO error
> 11 (Resource temporarily unavailable) on X server :4.____
> 
> __ __
> 
> XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server
> ":4"____
> 
> __ __
> 
> (gnome-settings-daemon:80264): Gdk-WARNING **: gnome-settings-daemon:
> Fatal IO error 11 (Resource temporarily unavailable) on X server :4.____
> 
> __ __
> 
>       after 120 requests (119 known processed) with 0 events remaining.____
> 
> Window manager warning: Fatal IO error 11 (Resource temporarily
> unavailable) on display ':4'.____
> 
> __ __
> 
> (gnome-panel:80263): Gdk-WARNING **: gnome-panel: Fatal IO error 11
> (Resource temporarily unavailable) on X server :4.____
> 
> 
> On Tue, Feb 21, 2017 at 5:25 PM, DRC <dco...@us...
> <mailto:dco...@us...>> wrote:
> 
>     Definitely should not be happening.  Since it's likely related to
>     TurboVNC, my suggestion would be to build the TurboVNC Server from
>     source and include debugging information in the build:
> 
>         sudo apt-get install gcc make git cmake libpam0g-dev libsm-dev
>     libice-dev libxext-dev libssl-dev
>         git clone https://github.com/TurboVNC/turbovnc.git
>     <https://github.com/TurboVNC/turbovnc.git>
>         cd turbovnc
>         mkdir build
>         cd build
>         cmake -G"Unix Makefiles" -DTVNC_BUILDNATIVE=0 -DTVNC_BUILDJAVA=0
>     -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
>         make
> 
>     Now launch the server with:
> 
>         ulimit -c 10000000
>         bin/vncserver -debug
> 
>     When the server crashes, it should leave a core file.  Load that core
>     file into gdb:
> 
>         gdb bin/Xvnc {core file}
> 
>     Type 'where' in gdb to print a stack trace.
> 
>     Create an issue in the TurboVNC GitHub tracker:
>     https://github.com/TurboVNC/turbovnc/issues/new
>     <https://github.com/TurboVNC/turbovnc/issues/new>
> 
>     and post the following:
> 
>         -- The stack trace you obtained above
>         -- The console output from the TurboVNC Server
>         -- What version of the RealVNC Viewer you were using (example:
>     4.1.2)
>         -- What client O/S you were using (examples: Windows 7, iOS 9, macOS
>     Sierra)
>         -- What RFB encoding you were using (examples: Hextile, ZRLE)
> 
>     All of that aside, while it is a bug for the RealVNC Viewer to crash the
>     TurboVNC Server, and I definitely want to fix that bug, I also cannot
>     recommend using the RealVNC Viewer.  The TurboVNC Viewer will be
>     necessary in order to achieve full performance with our server.
> 
> 
>     On 2/21/17 4:02 PM, Wei Liu wrote:
>     > Jason, DRC,
>     >
>     > The vnc session I created with TurboVNC crashes a few times. Can it be
>     > caused by my realVNC viewer? (seems hard to believe an incompatible
>     > viewer crashes the session) I haven't got a chance to use TurboVNC
>     > viewer due to other constraints.
>     >
>     > How to debug that crashes? I can put more information if I know how.
>     >
>     > I did run some OpenGL applications in the session. Not sure if it is
>     > related.
>     >
>     > Thank you very much,

[VirtualGL-Users] VirtualGL 2.5.2 has been released

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

Official binaries and source tarball are here:

https://sourceforge.net/projects/virtualgl/files/2.5.2/

Change log is here:

https://github.com/VirtualGL/virtualgl/releases/tag/2.5.2/

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

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

The OP's crash was specific to connecting with the RealVNC Viewer, so
that strongly suggests that there is a bug in the server related to
decoding non-Tight RFB protocol streams.

The "XIO:  fatal IO error 11" message always occurs when the TurboVNC
Server dies unexpectedly or is killed.

Also, please maintain the original thread subject when replying.


On 2/23/17 1:06 PM, Jason Kurtz wrote:
> *[VirtualGL-Users] The OP is having a problem with TurboVNC, not
> VirtualGL. The nVidia driver is not relevant to the problem. Please let
> me handle this. Thanks. On 2/22/17 1:48 PM, Jason Kurtz wrote: > Could
> you also run the following commands on the ubuntu server. > List all
> packages installed on the system. > sudo su - > dpkg
> --admindir=/var/lib/dpkg/ --get-selections > installed.packages > The
> current Kernel Version. > uname -a > installed.kernel > The jre
> installed on the system > The jdk the system is using > java -version 2>
> installed.java > The nvidia driver version loaded in the kernel. > dmesg
> | grep nvidia > installed.nvidia > I had a similar problem and when I
> upgraded to 16.04 lts and the latest > nvidia driver it stopped.
> <https://sourceforge.net/p/virtualgl/mailman/message/35684268/>*
> From: Jason Kurtz <tekcommnv@gm...> - 2017-02-23 14:28:31
> *Attachments:* Message as HTML
> <https://sourceforge.net/p/virtualgl/mailman/attachment/CADO%2BGxwCAOx9JSSURsAMKQt%2B_k-RaEJ%2BTLXj_AxfaCHmAFMmwA%40mail.gmail.com/1/>
> 
>     The OP is having a problem with TurboVNC, not VirtualGL. The nVidia
>     driver is not relevant to the problem. Please let me handle this.
>     Thanks. On 2/22/17 1:48 PM, Jason Kurtz wrote:
> 
> DRC, I was agreeing with you that it is not the nvidia driver and also
> disagreeing with you that it is a problem with Turbovnc.
> 
> This is a known issue affecting a lot of distro's including ubuntu 14.04.
> 
> The bug is in many versions of libxcb and is a 32-bit counter rollover
> problem that has been known for a few years:
> https://bugs.freedesktop.org/show_bug.cgi?id=71338
> 
> Not all versions of libxcb are affected libxcb-1.9-5 has it,
> libxcb-1.5-1 doesn't. From the bug list, 64-bits OS shouldn't be
> affected, but It has also triggered on at least one version.
> 
> It can be verified the following way.
> 
> The following program will crash in less than 15 minutes on affected
> libraries:
> 
> // Compile with: gcc test.c -lX11 && time ./a.out
> #include <X11/Xlib.h>
> void main(void) {
>     Display *d = XOpenDisplay(NULL);
>     if (d)
>      for(;;)
>         XNoOp(d);
> }
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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
> 

[VirtualGL-Users] The OP is having a problem with TurboVNC, not VirtualGL. The nVidia driver is not relevant to the problem

[Jason K. <tek...@gm...>]

*[VirtualGL-Users] The OP is having a problem with TurboVNC, not VirtualGL.
The nVidia driver is not relevant to the problem. Please let me handle
this. Thanks. On 2/22/17 1:48 PM, Jason Kurtz wrote: > Could you also run
the following commands on the ubuntu server. > List all packages installed
on the system. > sudo su - > dpkg --admindir=/var/lib/dpkg/
--get-selections > installed.packages > The current Kernel Version. > uname
-a > installed.kernel > The jre installed on the system > The jdk the
system is using > java -version 2> installed.java > The nvidia driver
version loaded in the kernel. > dmesg | grep nvidia > installed.nvidia > I
had a similar problem and when I upgraded to 16.04 lts and the latest >
nvidia driver it stopped.
<https://sourceforge.net/p/virtualgl/mailman/message/35684268/>*
From: Jason Kurtz <tekcommnv@gm...> - 2017-02-23 14:28:31
*Attachments:* Message as HTML
<https://sourceforge.net/p/virtualgl/mailman/attachment/CADO%2BGxwCAOx9JSSURsAMKQt%2B_k-RaEJ%2BTLXj_AxfaCHmAFMmwA%40mail.gmail.com/1/>

> The OP is having a problem with TurboVNC, not VirtualGL. The nVidia
> driver is not relevant to the problem. Please let me handle this. Thanks.
> On 2/22/17 1:48 PM, Jason Kurtz wrote:
>
> DRC, I was agreeing with you that it is not the nvidia driver and also
disagreeing with you that it is a problem with Turbovnc.

This is a known issue affecting a lot of distro's including ubuntu 14.04.

The bug is in many versions of libxcb and is a 32-bit counter rollover
problem that has been known for a few years:
https://bugs.freedesktop.org/show_bug.cgi?id=71338

Not all versions of libxcb are affected libxcb-1.9-5 has it, libxcb-1.5-1
doesn't. From the bug list, 64-bits OS shouldn't be affected, but It has
also triggered on at least one version.

It can be verified the following way.

The following program will crash in less than 15 minutes on affected
libraries:

// Compile with: gcc test.c -lX11 && time ./a.out
#include <X11/Xlib.h>
void main(void) {
    Display *d = XOpenDisplay(NULL);
    if (d)
     for(;;)
        XNoOp(d);
}

Re: [VirtualGL-Users] Android Donations for DRC

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

On 2/23/17 8:41 AM, Jason Kurtz wrote:
> Actually alot of projects use and depend on VirtualGL. I think the
> intersection of GPL apps that could connect to it on Android. You would
> get alot more funding then you think. The user supported pro version of
> bvnc is a good example with 1-5k purchases at 5 bucks a pop. I have
> compiled it on armhf running custom ubuntu 14.04 rom I made for one of
> my droid boxes to dualboot ubuntu and used the oracle jre and it blew
> away everything on arm system. 

It may be possible to monetize the Android viewer once it's developed,
but as an independent developer, I cannot engage in that kind of
speculative venture.  If I spent two months of full-time labor
productizing this and it didn't earn money quickly, I'd be unable to pay
my rent.  If the app did make money, then it would likely do so on the
strength of users outside of the existing VirtualGL/TurboVNC community,
and that would put me in the position of doing a lot of work that
distracts from the fundamental goals of this project (for instance,
supporting the Android viewer with servers other than ours.)  My goal in
producing an Android TurboVNC viewer would be primarily to extend the
reach of remote hardware-accelerated 3D applications to that client
platform, not to produce a general-purpose VNC viewer for Android.
That's why I feel that the best business model would be to find a
company that needs the technology, encourage them to pay for its
development, and release the app for free.  A free app would reduce the
pressure on me to make the app be all things to all users.  It's a
matter of resource constraints as much as anything.  I have a lot on my
plate right now, and there is a lot of lower-hanging fruit than this.
Creating a kickstarter and such takes time that I don't have.

My thoughts are based on 12+ years of experience as the primary
developer and sole maintainer of these projects, as well as 8+ years of
having to solicit money from the VirtualGL and TurboVNC and
libjpeg-turbo communities in order to pay my bills.  I don't claim to be
100% right all the time, but I have a better chance of predicting the
behavior of the communities I created than anyone else does.  My gut
feeling is that they may be willing to pony up a buck for this app after
it's created, but probably not before.

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

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

Doubtful.  That error occurs all the time and is not related to what the
OP is talking about.  "Please let me handle it" means please stop
interjecting.  I am trying to work with the OP to diagnose what might be
a bug in TurboVNC.  No offense, but your diagnoses are not very well
informed and are not helping the situation.

On 2/23/17 8:28 AM, Jason Kurtz wrote:
> I agree DRC. Its looks suspiciously like this bug https://bugs.freedesktop.org/show_bug.cgi?id=71338 . Which causes XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0" . Im posting the bug report because it will let you narrow down the search with GDB DRC.

Re: [VirtualGL-Users] Android Donations for DRC

[Jason K. <tek...@gm...>]

From: DRC <dcommander@us...> - 2017-02-22 23:43:53

On 2/22/17 3:54 PM, Jason Kurtz wrote:
> I understand, Have you considered a kickstarter. I know there is a large
> base using turbovnc and even a larger base using virtualgl. There's not
> really a great alternative. I would be happy to donate to something like
> that. bvnc pro which is the closet has already made 5-20k on playstore.

I don't think enough people care about this specific project to make a
kickstarter worthwhile.  The intersection of people who use VirtualGL
and people who use Android devices is probably very small.  It's more
likely that this funding would come from a company who sees a potential
for simplifying or expanding its remote display infrastructure using
Android devices.  I suspect I'd have a much easier time securing funding
for an iOS viewer, but unfortunately, that's a non-starter due to the
fact that the iOS App Store doesn't allow GPL-licensed code.

Actually alot of projects use and depend on VirtualGL. I think the
intersection of GPL apps that could connect to it on Android. You would get
alot more funding then you think. The user supported pro version of bvnc is
a good example with 1-5k purchases at 5 bucks a pop. I have compiled it on
armhf running custom ubuntu 14.04 rom I made for one of my droid boxes to
dualboot ubuntu and used the oracle jre and it blew away everything on arm
system.

[VirtualGL-Users] The OP is having a problem with TurboVNC, not VirtualGL. The nVidia driver is not relevant to the problem. Please let me handle this. Thanks. On 2/22/17 1:48 PM, Jason Kurtz wrote: > Could you also run the following commands on the ubuntu server. > List all packages installed on the system. > sudo su - > dpkg --admindir=/var/lib/dpkg/ --get-selections > installed.packages > The current Kernel Version. > uname -a > installed.kernel > The jre installed on the system > The jdk the system is using > java -version 2> installed.java > The nvidia driver version loaded in the kernel. > dmesg | grep nvidia > installed.nvidia > I had a similar problem and when I upgraded to 16.04 lts and the latest > nvidia driver it stopped.

[Jason K. <tek...@gm...>]

The OP is having a problem with TurboVNC, not VirtualGL.  The nVidia
driver is not relevant to the problem.  Please let me handle this.  Thanks.

On 2/22/17 1:48 PM, Jason Kurtz wrote:
> Could you also run the following commands on the ubuntu server.
> List all packages installed on the system.
> sudo su -
> dpkg --admindir=/var/lib/dpkg/ --get-selections > installed.packages
> The current Kernel Version.
> uname -a > installed.kernel
> The jre installed on the system
> The jdk the system is using
> java -version 2> installed.java
> The nvidia driver version loaded in the kernel.
> dmesg | grep nvidia > installed.nvidia
> I had a similar problem and when I upgraded to 16.04 lts and the latest
> nvidia driver it stopped.

I agree DRC. Its looks suspiciously like this bug
https://bugs.freedesktop.org/show_bug.cgi?id=71338 . Which causes XIO:
 fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
. Im posting the bug report because it will let you narrow down the
search with GDB DRC.

Re: [VirtualGL-Users] Android Donations for DRC

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

On 2/22/17 3:54 PM, Jason Kurtz wrote:
> I understand, Have you considered a kickstarter. I know there is a large
> base using turbovnc and even a larger base using virtualgl. There's not
> really a great alternative. I would be happy to donate to something like
> that. bvnc pro which is the closet has already made 5-20k on playstore. 

I don't think enough people care about this specific project to make a
kickstarter worthwhile.  The intersection of people who use VirtualGL
and people who use Android devices is probably very small.  It's more
likely that this funding would come from a company who sees a potential
for simplifying or expanding its remote display infrastructure using
Android devices.  I suspect I'd have a much easier time securing funding
for an iOS viewer, but unfortunately, that's a non-starter due to the
fact that the iOS App Store doesn't allow GPL-licensed code.

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

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

My understanding is that the TurboVNC Server is actually crashing.
Maybe I misunderstood.  In any case, it shouldn't be dumping the
connection.  Our server should support RealVNC viewers.


On 2/22/17 3:42 PM, Jason Kurtz wrote:
> I have seen that error before using realvnc, Its because it can not
> negotiate from the client a compression method so it dumps the connection.
> You need to switch from realvnc to turbovnc on the windows client
> machines like DRC says. Just grab turbovnc client for the windows machines.

[VirtualGL-Users] Android Donations for DRC

[Jason K. <tek...@gm...>]

>
> if I had to do this from scratch, I could easily see it taking
> more than 100 hours to get a proof of concept working, and more than
> that to fully test it, document it, produce builds in a somewhat
> automated manner, etc.  There could be some reuse of the existing Java
> classes, but I'm guessing that maybe only half of that code could be
> reused (if that.)  Unclear whether I could reuse any of the existing
> encryption classes or what other low-level features would have to be
> re-written to accommodate the Android O/S.


I understand, Have you considered a kickstarter. I know there is a large
base using turbovnc and even a larger base using virtualgl. There's not
really a great alternative. I would be happy to donate to something like
that. bvnc pro which is the closet has already made 5-20k on playstore.

[VirtualGL-Users] server have multi GPUs not connected to physical screen

[Jason K. <tek...@gm...>]

I have seen that error before using realvnc, Its because it can not
negotiate from the client a compression method so it dumps the connection.
You need to switch from realvnc to turbovnc on the windows client machines
like DRC says. Just grab turbovnc client for the windows machines.

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

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

The OP is having a problem with TurboVNC, not VirtualGL.  The nVidia
driver is not relevant to the problem.  Please let me handle this.  Thanks.

On 2/22/17 1:48 PM, Jason Kurtz wrote:
> Could you also run the following commands on the ubuntu server.
> List all packages installed on the system.
> sudo su -
> dpkg --admindir=/var/lib/dpkg/ --get-selections > installed.packages
> The current Kernel Version.
> uname -a > installed.kernel
> The jre installed on the system
> The jdk the system is using 
> java -version 2> installed.java
> The nvidia driver version loaded in the kernel.
> dmesg | grep nvidia > installed.nvidia
> I had a similar problem and when I upgraded to 16.04 lts and the latest
> nvidia driver it stopped.

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

[Jason K. <tek...@gm...>]

Could you also run the following commands on the ubuntu server.
List all packages installed on the system.
sudo su -
dpkg --admindir=/var/lib/dpkg/ --get-selections > installed.packages
The current Kernel Version.
uname -a > installed.kernel
The jre installed on the system
The jdk the system is using
java -version 2> installed.java
The nvidia driver version loaded in the kernel.
dmesg | grep nvidia > installed.nvidia
I had a similar problem and when I upgraded to 16.04 lts and the latest
nvidia driver it stopped.

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

[Wei L. <wei...@gm...>]

Thanks DRC for the information. With all the constraints in our compute
environment, I do want to debug that issue. Here are the log of that
session (may not be helpful), and I will try to follow the debug steps and
put it here.

//////// crash log ///////////////////////

/02/2017 14:51:09 Got connection from client 159.70.104.60

21/02/2017 14:51:09   (other clients 159.70.87.121)

21/02/2017 14:51:09 Using protocol version 3.8

21/02/2017 14:51:12 Full-control authentication enabled for 159.70.104.60

21/02/2017 14:51:12 Enabling full-color cursor updates for client
159.70.104.60

21/02/2017 14:51:12 rfbProcessClientNormalMessage: ignoring unknown
encoding -223 (ffffff21)

21/02/2017 14:51:12 Using ZRLE encoding for client 159.70.104.60

21/02/2017 14:51:12 rfbProcessClientNormalMessage: ignoring unknown
encoding 15 (f)

21/02/2017 14:51:12 Pixel format for client 159.70.104.60:

21/02/2017 14:51:12   8 bpp, depth 8

21/02/2017 14:51:12   uses a colour map (not true colour).

21/02/2017 14:51:13 Pixel format for client 159.70.104.60:

21/02/2017 14:51:13   32 bpp, depth 24, little endian

21/02/2017 14:51:13   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0

21/02/2017 14:51:13   no translation needed

21/02/2017 14:51:13 Enabling full-color cursor updates for client
159.70.104.60

21/02/2017 14:51:13 rfbProcessClientNormalMessage: ignoring unknown
encoding -223 (ffffff21)

21/02/2017 14:51:13 Using hextile encoding for client 159.70.104.60

21/02/2017 14:51:13 rfbProcessClientNormalMessage: ignoring unknown
encoding 15 (f)

21/02/2017 15:06:44 rfbProcessClientNormalMessage: read: Connection timed
out

21/02/2017 15:06:44 Client 159.70.87.121 gone

21/02/2017 15:06:44 Statistics:

21/02/2017 15:06:44   key events received 686, pointer events 136033

21/02/2017 15:06:44   framebuffer updates 21954, rectangles 62990, bytes
-171025480

21/02/2017 15:06:44     cursor shape updates 1581, bytes 3577869

21/02/2017 15:06:44     raw rectangles 1, bytes 17292

21/02/2017 15:06:44     copyRect rectangles 1696, bytes 27136

21/02/2017 15:06:44     hextile rectangles 59711, bytes -174662874

21/02/2017 15:06:44

(nautilus:80266): Gdk-WARNING **: nautilus: Fatal IO error 11 (Resource
temporarily unavailable) on X server :4.





(gnome-terminal:80262): Gdk-WARNING **: gnome-terminal: Fatal IO error 11
(Resource temporarily unavailable) on X server :4.



XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":4"



(gnome-settings-daemon:80264): Gdk-WARNING **: gnome-settings-daemon: Fatal
IO error 11 (Resource temporarily unavailable) on X server :4.



      after 120 requests (119 known processed) with 0 events remaining.

Window manager warning: Fatal IO error 11 (Resource temporarily
unavailable) on display ':4'.



(gnome-panel:80263): Gdk-WARNING **: gnome-panel: Fatal IO error 11
(Resource temporarily unavailable) on X server :4.

On Tue, Feb 21, 2017 at 5:25 PM, DRC <dco...@us...>
wrote:

> Definitely should not be happening.  Since it's likely related to
> TurboVNC, my suggestion would be to build the TurboVNC Server from
> source and include debugging information in the build:
>
>     sudo apt-get install gcc make git cmake libpam0g-dev libsm-dev
> libice-dev libxext-dev libssl-dev
>     git clone https://github.com/TurboVNC/turbovnc.git
>     cd turbovnc
>     mkdir build
>     cd build
>     cmake -G"Unix Makefiles" -DTVNC_BUILDNATIVE=0 -DTVNC_BUILDJAVA=0
> -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
>     make
>
> Now launch the server with:
>
>     ulimit -c 10000000
>     bin/vncserver -debug
>
> When the server crashes, it should leave a core file.  Load that core
> file into gdb:
>
>     gdb bin/Xvnc {core file}
>
> Type 'where' in gdb to print a stack trace.
>
> Create an issue in the TurboVNC GitHub tracker:
> https://github.com/TurboVNC/turbovnc/issues/new
>
> and post the following:
>
>     -- The stack trace you obtained above
>     -- The console output from the TurboVNC Server
>     -- What version of the RealVNC Viewer you were using (example: 4.1.2)
>     -- What client O/S you were using (examples: Windows 7, iOS 9, macOS
> Sierra)
>     -- What RFB encoding you were using (examples: Hextile, ZRLE)
>
> All of that aside, while it is a bug for the RealVNC Viewer to crash the
> TurboVNC Server, and I definitely want to fix that bug, I also cannot
> recommend using the RealVNC Viewer.  The TurboVNC Viewer will be
> necessary in order to achieve full performance with our server.
>
>
> On 2/21/17 4:02 PM, Wei Liu wrote:
> > Jason, DRC,
> >
> > The vnc session I created with TurboVNC crashes a few times. Can it be
> > caused by my realVNC viewer? (seems hard to believe an incompatible
> > viewer crashes the session) I haven't got a chance to use TurboVNC
> > viewer due to other constraints.
> >
> > How to debug that crashes? I can put more information if I know how.
> >
> > I did run some OpenGL applications in the session. Not sure if it is
> > related.
> >
> > Thank you very much,
>
> ------------------------------------------------------------
> ------------------
> 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
>

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

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

Definitely should not be happening.  Since it's likely related to
TurboVNC, my suggestion would be to build the TurboVNC Server from
source and include debugging information in the build:

    sudo apt-get install gcc make git cmake libpam0g-dev libsm-dev
libice-dev libxext-dev libssl-dev
    git clone https://github.com/TurboVNC/turbovnc.git
    cd turbovnc
    mkdir build
    cd build
    cmake -G"Unix Makefiles" -DTVNC_BUILDNATIVE=0 -DTVNC_BUILDJAVA=0
-DCMAKE_BUILD_TYPE=RelWithDebInfo ..
    make

Now launch the server with:

    ulimit -c 10000000
    bin/vncserver -debug

When the server crashes, it should leave a core file.  Load that core
file into gdb:

    gdb bin/Xvnc {core file}

Type 'where' in gdb to print a stack trace.

Create an issue in the TurboVNC GitHub tracker:
https://github.com/TurboVNC/turbovnc/issues/new

and post the following:

    -- The stack trace you obtained above
    -- The console output from the TurboVNC Server
    -- What version of the RealVNC Viewer you were using (example: 4.1.2)
    -- What client O/S you were using (examples: Windows 7, iOS 9, macOS
Sierra)
    -- What RFB encoding you were using (examples: Hextile, ZRLE)

All of that aside, while it is a bug for the RealVNC Viewer to crash the
TurboVNC Server, and I definitely want to fix that bug, I also cannot
recommend using the RealVNC Viewer.  The TurboVNC Viewer will be
necessary in order to achieve full performance with our server.


On 2/21/17 4:02 PM, Wei Liu wrote:
> Jason, DRC, 
> 
> The vnc session I created with TurboVNC crashes a few times. Can it be
> caused by my realVNC viewer? (seems hard to believe an incompatible
> viewer crashes the session) I haven't got a chance to use TurboVNC
> viewer due to other constraints. 
> 
> How to debug that crashes? I can put more information if I know how. 
> 
> I did run some OpenGL applications in the session. Not sure if it is
> related. 
> 
> Thank you very much,

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

[Wei L. <wei...@gm...>]

Jason, DRC,

The vnc session I created with TurboVNC crashes a few times. Can it be
caused by my realVNC viewer? (seems hard to believe an incompatible viewer
crashes the session) I haven't got a chance to use TurboVNC viewer due to
other constraints.

How to debug that crashes? I can put more information if I know how.

I did run some OpenGL applications in the session. Not sure if it is
related.

Thank you very much,

On Wed, Feb 15, 2017 at 6:12 PM, Jason Kurtz <tek...@gm...> wrote:

> Thank you very much. It worked! My application can show beautiful 3D
>> rendering in VNC with vglrun.
>> I just use another vncviewer (realvnc). I will try TurboVNC later, but
>> even
>> now the performance is pretty good.
>> Thank you again for the help. This is great tool.
>
>
> You really should use Turbovnc  instead of realvnc with the oracle 8 jdk.
> I have tested every remote desktop solution and it is the fastest and
> stablest.
>
> ------------------------------------------------------------
> ------------------
> 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
>
>

Re: [VirtualGL-Users] New year same question time for DRC

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

Good question.  Our current Java viewer (which, in combination with
native glueware, is used as the TurboVNC Viewer on non-Windows
platforms) was originally a by-product of an effort to produce an
Android TurboVNC Viewer back in 2012, but the project was never fully
completed.  Because I'm an independent developer, research projects like
that often have to be implemented piecemeal as funding comes in for the
various pieces, and it's often the case that, once a certain "critical
mass" of pieces is implemented, it will be much easier to secure the
funding for the remaining pieces.

By the time 2012 rolled around, the JNI interface for libjpeg-turbo
already existed as a result of an unrelated project.  Santos ponied up
research funding for the next steps, because they were interested in
using dockable multi-core Android phones as TurboVNC clients.  I was
able to use that funding to clean up, integrate, and test the initial
NEON optimizations for libjpeg-turbo (from Nokia and Linaro), as well as
to work with Brian (TigerVNC developer) to bring over his Java TigerVNC
Viewer code and enhance it so that it behaved more like the Windows
TurboVNC Viewer and so that it could use libjpeg-turbo via JNI.  The
reasoning was: get the Java TurboVNC Viewer infrastructure working
first, then look at porting the GUI to Android from there.

Unfortunately, the dockable Android phones never really materialized
with the performance and features necessary for Santos to achieve what
they needed (they drive 4-megapixel displays), and as time went on,
Microsoft started producing tablet products that will run the native x86
Windows TurboVNC Viewer, so there hasn't been a big push for an Android
TurboVNC Viewer in industry.  I'm still interested in producing one,
however.

Since the latest release of Android now includes libjpeg-turbo, that
might make things a bit easier now than it was in 2012, since it should
hypothetically be possible to release a full-performance TurboVNC Viewer
for Android that doesn't require a bundled NDK library.  The real trick
is going to be porting the GUI.  I am adept at Swing programming, but
Android GUI programming-- although it has a few of the same constructs--
is quite a bit different than Swing, and it would basically be necessary
to design a whole new GUI from scratch that is mobile-friendly and that
implements the same features as the PC TurboVNC viewers.  All of the
various dialogs and menus would have to be turned into
touch-screen-friendly configuration screens, and I'd have to implement
some mobile-friendly way to handle zooming, panning, scaling, resizing,
etc.  If I had to do this from scratch, I could easily see it taking
more than 100 hours to get a proof of concept working, and more than
that to fully test it, document it, produce builds in a somewhat
automated manner, etc.  There could be some reuse of the existing Java
classes, but I'm guessing that maybe only half of that code could be
reused (if that.)  Unclear whether I could reuse any of the existing
encryption classes or what other low-level features would have to be
re-written to accommodate the Android O/S.

GUI-wise, it might be quicker to build upon an existing GPL-licensed
Android VNC viewer GUI and simply enhance it for our needs.  That would
certainly reduce the cost of the initial PoC.  Regardless, though, this
is either going to require someone donating a lot of labor or donating a
lot of money.


On 2/16/17 5:27 PM, Jason Kurtz wrote:
> DRC,
> 
> I know this is a question that comes up every year or more. I am
> wondering how much do you estimate it would take to make a turbovnc
> Android client. I have already complied and used virtualgl and turbovnc
> on ARM Hard Float, and ARM 64. Even though there are other vnc clients.
> When I tested them on the arm arch. Turbovnc blew all the other options
> away. 

[VirtualGL-Users] New year same question time for DRC

[Jason K. <tek...@gm...>]

DRC,

I know this is a question that comes up every year or more. I am wondering
how much do you estimate it would take to make a turbovnc Android client. I
have already complied and used virtualgl and turbovnc on ARM Hard Float,
and ARM 64. Even though there are other vnc clients. When I tested them on
the arm arch. Turbovnc blew all the other options away.

Regards,

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

[Jason K. <tek...@gm...>]

>
> Thank you very much. It worked! My application can show beautiful 3D
> rendering in VNC with vglrun.
> I just use another vncviewer (realvnc). I will try TurboVNC later, but even
> now the performance is pretty good.
> Thank you again for the help. This is great tool.


You really should use Turbovnc  instead of realvnc with the oracle 8 jdk. I
have tested every remote desktop solution and it is the fastest and
stablest.

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

[Wei L. <wei...@gm...>]

Thank you very much. It worked! My application can show beautiful 3D
rendering in VNC with vglrun.

I just use another vncviewer (realvnc). I will try TurboVNC later, but even
now the performance is pretty good.

Thank you again for the help. This is great tool.

On Wed, Feb 15, 2017 at 12:43 PM, DRC <dco...@us...>
wrote:

> That is all normal.  The rmmod error is telling you that the nVidia
> module is in use, which is why the subsequent message tells you to run
> 'rmmod nvidia' with the DM stopped in order to remove the module.  That
> is only necessary if you want to activate VGL without rebooting.  Since
> you rebooted, you're good.
>
> The TurboVNC display will not have a GLX extension.  That's why
> VirtualGL exists.  VirtualGL will redirect GLX calls from an OpenGL
> application to display :0, which has a hardware-accelerated GLX extension.
>
> Connect to the TurboVNC session and run
>
>     vglrun {your_application}
>
> and it should work.
>
>
> On 2/15/17 11:38 AM, Wei Liu wrote:
> > Darrel,
> >
> > Thanks for the information. I followed your suggestion and created a
> > xorg.conf file. Then I stopped the display manager, and run
> > 'vglserver_config'. After answering questions, I got the following error:
> >
> > ====== vglserver_config output =======
> >
> > .. Creating /etc/modprobe.d/virtualgl.conf to set requested permissions
> > for____
> >
> >     /dev/nvidia* ...____
> >
> > ... Attempting to remove nvidia module from memory so device
> permissions____
> >
> >     will be reloaded ...____
> >
> > *rmmod: ERROR: Module nvidia is in use by: nvidia_modeset nvidia_uvm____*
> >
> > ... Granting write permission to /dev/nvidia-uvm /dev/nvidia-uvm-tools
> > /dev/nvid      ia0 /dev/nvidia1 /dev/nvidia2 /dev/nvidia3 /dev/nvidia4
> > /dev/nvidia5 /dev/nvidia      6 /dev/nvidia7 /dev/nvidiactl for all
> > users ...____
> >
> > ... Granting write permission to /dev/dri/card0 for all users ...____
> >
> > ... /etc/X11/xorg.conf has been saved as /etc/X11/xorg.conf.orig.vgl
> ...____
> >
> > ... Modifying /etc/X11/xorg.conf to enable DRI permissions____
> >
> >     for all users ...____
> >
> > ... /etc/lightdm/lightdm.conf has been saved as
> > /etc/lightdm/lightdm.conf.orig.v      gl ...____
> >
> > ... Adding display-setup-script=xhost +LOCAL: to
> > /etc/lightdm/lightdm.conf ...____
> >
> > __ __
> >
> > Done. You must restart the display manager for the changes to take
> > effect.____
> >
> > __ __
> >
> > IMPORTANT NOTE: Your system uses modprobe.d to set device permissions.
> > You____
> >
> > must execute rmmod nvidia with the display manager stopped in order for
> > the____
> >
> > new device permission settings to become effective.
> >
> > ===== end of vglserver_config =======
> >
> >
> > I chose 'no' to all the questions, since I don't worry about security in
> > our environment.
> >
> >
> > Then I installed TubroVNC and run vncserver to get a new vnc session at
> > port 3.
> >
> >
> > If I run DISPLAY=:0 glxinfo, I can see direct rendering is yes, and glx
> > vendor string is Nvidia, but if I run DISPLAY=:3 glxinfo, I got error
> > "could not find RGB GLX visual or fbconfig".
> >
> >
> > xdpyinfo -display :3 shows vendor string is TubroVNC...
> >
> >
> > I also reboot the system, but got the same results. I attached the
> > output log of runnining xdpyinfo and glxinfo on port 0 and 3
> > respectively. (the file name has 0 and 3 for the port number).
> >
> >
> > Did I miss anything? Where should I start troubleshooting?
> >
> >
> > Thanks for the help!
> >
> >
> >
> >
> >
> > On Tue, Feb 14, 2017 at 11:53 PM, DRC <dco...@us...
> > <mailto:dco...@us...>> wrote:
> >
> >     You can use headless GPUs with VirtualGL.  Install the nVidia
> >     proprietary drivers (I believe Ubuntu provides a package for these),
> >     then run:
> >
> >         nvidia-xconfig -a --use-display-device=None --virtual=1920x1200
> >
> >     (I don't think the resolution specified for --virtual matters, since
> >     it's headless.)
> >
> >     Run vglserver_config to grant access to the X server while the
> display
> >     manager is sitting at the login prompt, then restart the display
> >     manager, and ideally you should be able to do
> >
> >         xauth merge /etc/opt/VirtualGL/vgl_xauth_key
> >         DISPLAY=:0 glxinfo
> >
> >     and glxinfo should report that it is using the nVidia OpenGL
> renderer.
> >
> >     On 2/14/17 10:03 PM, Wei Liu wrote:
> >     > Hi VirtualGL users,
> >     >
> >     > I need your help on a set up of virtualGL, or decide if I can use
> >     > virtualGL to solve my problem.
> >     >
> >     > My setup: a Ubunt 14.04 server called 'roundvalley' has multiple
> Nvidia
> >     > GPUs for parallel computing, but they do not have any
> >     > VGA/DVI/DisplayPort and not connected to monitor. The only
> onboard-card
> >     > connected to a monitor does not have 3D capability, and Ubuntu
> >     > automatically load a kernel driver module (I forgot the module
> name) for
> >     > this onboard card.
> >     >
> >     > Client side is Windows. My goal is to use VNC to connect to the
> server
> >     > and run 3D application (need OpenGL) in my VNC session.
> >     >
> >     > My question is, can I configure virtualGL to use any of Nvidia GPU
> even
> >     > they are not used for display currently?
> >     >
> >     > I read the official document and found:
> >     > ==== user doc =====
> >     > 6.2 Using VirtualGL with Multiple GPUs
> >     >
> >     > VirtualGL can redirect the OpenGL commands from a 3D application
> to any
> >     > GPU in the server machine. In order for this to work, however, all
> of
> >     > the GPUs must be attached to different screens on the same X
> server or
> >     > to different X servers.
> >     > ====== end user doc ======
> >     >
> >     > Does it mean the GPU need to connect to physical screens, or some
> >     > definitions in X.org file?
> >     >
> >     > I appreciate your help.
> >     >
> >     > Thanks,
> >     > Wei
> >
> >
> >     ------------------------------------------------------------
> ------------------
> >     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...
> >     <mailto:Vir...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> >     <https://lists.sourceforge.net/lists/listinfo/virtualgl-users>
> >
> >
> >
> >
> > ------------------------------------------------------------
> ------------------
> > 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
> >
>
> ------------------------------------------------------------
> ------------------
> 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
>

Re: [VirtualGL-Users] Easy setup for Ubuntu. and Windows machine.

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

VirtualGL works and is supported on X proxies other than TurboVNC, but
The VirtualGL Project does not endorse any X proxies other than
TurboVNC.  Please understand that I am able to run this project only
because of funded development and support opportunities that include
both VirtualGL and TurboVNC.  Income from VirtualGL alone would be
insufficient to keep the project afloat.

I do not deny that Xpra does some things that TurboVNC doesn't (seamless
windows, for instance), but TurboVNC also has a lot of features that
Xpra lacks.  TurboVNC is also a proven enterprise product that is being
used in a variety of mission-critical installations by various
corporations and large academic/scientific institutions.  It's also,
frankly, easier to use than Xpra.  If the user needed a feature that was
not available in TurboVNC, then I myself would have steered them to
another X proxy, but that was not the case.

In short, let's please try to keep this list as agnostic as possible in
terms of X proxy recommendations and make those recommendations based
purely on technical need.

Signed,
The Management

On 2/15/17 12:02 PM, Jason Kurtz wrote:
> First off I would recommend the following setup
> Ubuntu Machine 
> Install VirtualGL, Turbojpeg, Synergy, Xpra
> 
> Windows, Machine 
> Installl Synergy, Xpra
> 
> This setup will allow you to run a full 3d desktop and just the 3d
> applications you need. Example
> Here are the two scripts I use. To start the server its just one command 
> #startserver
> xpra start --max-size=1280x720 --start-child=start3dprogram
> --speaker=disabled  --bind-tcp=19
> 2.168.2.1:1000 <http://2.168.2.1:1000>
> 
> #start3dprogram
> vglclient -detach  
> vglrun -q 50 -c rgb  /opt/bin/3dprogram
> 
> Then use Synergy to connect the keyboard.
> 
> 
> Then you can just connect from the Windows client.
> With this setup you have, clipboard,Audio,Print, 3d gl support and you
> save resources from running just the 3d app. The configuration is also
> all gui front end through xpra and synergy.