I made a few unseccessful attempts to solve the problem, by reinstalling the xorg fonts, specify the -fp option with /usr/share/fonts/75dpi / 100dpi, uninstalling every packages I suspected could interfere with Turbovnc (vine vinagre, Tigervnc, etc) but couldn't get vncserver to run properly.
I've been told the problem could come from my distro, since some file locations on arch linux are quite unconventional...?
Hope you can help me =)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unrecognizedoption:/var/run/gdm/auth-for-bruno-nl5i8s/databaseuse:X[:<display>][option]-a# mouse acceleration (pixels)-acdisableaccesscontrolrestrictions-auditintsetaudittraillevel-authfileselectauthorizationfilebcenablebugcompatibility-bsdisableanybackingstoresupport-cturnsoffkey-clickc# key-click volume (0-100)-ccintdefaultcolorvisualclass-cofilecolordatabasefile-coregeneratecoredumponfatalerror-dpiintscreenresolutionindotsperinch-deferglyphs[none|all|16]deferloadingof[no|all|16-bit]glyphs-f# bell base (0-100)-fcstringcursorfont-fnstringdefaultfontname-fpstringdefaultfontpath-helpprintsmessagewiththeseoptions-Iignoreallremainingarguments-ldintlimitdataspacetoNKb-lfintlimitnumberofopenfilestoN-lsintlimitstackspacetoNKb-nolockdisablethelockingmechanism-logoenablelogoinscreensavernologodisablelogoinscreensaver-nolistenstringdon't listen on protocol-p# screen-saver pattern duration (minutes)-pnacceptfailuretolistenonallports-nopnrejectfailuretolistenonallports-rturnsoffauto-repeatrturnsonauto-repeat-render[default|mono|gray|color]setrendercolorallocpolicy-norenderdisablerenderextension-s# screen-saver timeout (minutes)-sudisableanysaveundersupport-t# mouse threshold (pixels)-terminateterminateatserverreset-to# connection time out-tstdisabletestingextensionsttyxxserverstartedfrominiton/dev/ttyxxvvideoblankingforscreen-saver-vscreen-saverwithoutvideoblanking-wmWhenMappeddefaultbacking-store-xstringloadsnamedextensionatinittime-queryhost-namecontactnamedhostforXDMCP-broadcastbroadcastforXDMCP-indirecthost-namecontactnamedhostforindirectXDMCP-portport-numUDPportnumbertosendmessagesto-onceTerminateserverafteronesession-classdisplay-classspecifydisplayclasstosendinmanage-cookiexdm-auth-bitsspecifythemagiccookieforXDMCP-displayIDdisplay-idmanufacturerdisplayIDforrequest-geometryWxHsetframebufferwidth&height-depthDsetframebufferdepth-pixelformatformatsetpixelformat(BGRnnnorRGBnnn)-udpinputportportUDPportforkeyboard/pointerdata-rfbportportTCPportforRFBprotocol-rfbwaittimemaxtimeinmstowaitforRFBclient-nocursordon't display a cursor-rfbauthpasswd-fileenableVNCpasswordauthentication-otpauthenableone-timepassword(OTP)authentication-pamauthenablePAMuser/passwordauthentication-noreversedisablereverseconnections-noclipboardsenddisableserver->clientclipboardsynchronization-noclipboardrecvdisableclient->serverclipboardsynchronization-nocutbuffersyncdisableclipboardsynchronizationforapplicationsthatusethe(obsolete)Xcutbuffer-idletimeoutSexitifSsecondselapsewithnoVNCviewerconnections-httpddirservefilesfromthespecifieddirectoryusingHTTP-httpportportportforHTTPserver-deferupdatetimetimeinmstodeferupdates(default40)-noflowcontrolwhencontinuousupdatesareenabled,sendupdateswhetherornottheclientisreadytoreceivethem-alrSenableautomaticlosslessrefreshandsettimertoSseconds(Sisfloatingpoint)-interframealwaysuseinterframecomparison-nointerframeneveruseinterframecomparison-economictranslatelessmemoryhungrytranslation-desktopnameVNCdesktopname(defaultx11)-alwayssharedalwaystreatnewclientsasshared-neversharednevertreatnewclientsasshared-dontdisconnectdon't disconnect existing clients when a new non-sharedconnectioncomesin(refusenewconnectioninstead)-viewonlyonlyletclientsviewtheremotedesktop-localhostonlyallowconnectionsfromlocalhost-interfaceipaddronlybindtospecifiedinterfaceaddress-ipv6enableIPv6support-inetdXvncislaunchedbyinetd-compatiblekbdsetMETAkey=ALTkeyasintheoriginalVNC-versionreportXvncversiononstderrUnrecognizedoption:/var/run/gdm/auth-for-bruno-nl5i8s/databaseuse:X[:<display>][option]-a# mouse acceleration (pixels)-acdisableaccesscontrolrestrictions-auditintsetaudittraillevel-authfileselectauthorizationfilebcenablebugcompatibility-bsdisableanybackingstoresupport-cturnsoffkey-clickc# key-click volume (0-100)-ccintdefaultcolorvisualclass-cofilecolordatabasefile-coregeneratecoredumponfatalerror-dpiintscreenresolutionindotsperinch-deferglyphs[none|all|16]deferloadingof[no|all|16-bit]glyphs-f# bell base (0-100)-fcstringcursorfont-fnstringdefaultfontname-fpstringdefaultfontpath-helpprintsmessagewiththeseoptions-Iignoreallremainingarguments-ldintlimitdataspacetoNKb-lfintlimitnumberofopenfilestoN-lsintlimitstackspacetoNKb-nolockdisablethelockingmechanism-logoenablelogoinscreensavernologodisablelogoinscreensaver-nolistenstringdon't listen on protocol-p# screen-saver pattern duration (minutes)-pnacceptfailuretolistenonallports-nopnrejectfailuretolistenonallports-rturnsoffauto-repeatrturnsonauto-repeat-render[default|mono|gray|color]setrendercolorallocpolicy-norenderdisablerenderextension-s# screen-saver timeout (minutes)-sudisableanysaveundersupport-t# mouse threshold (pixels)-terminateterminateatserverreset-to# connection time out-tstdisabletestingextensionsttyxxserverstartedfrominiton/dev/ttyxxvvideoblankingforscreen-saver-vscreen-saverwithoutvideoblanking-wmWhenMappeddefaultbacking-store-xstringloadsnamedextensionatinittime-queryhost-namecontactnamedhostforXDMCP-broadcastbroadcastforXDMCP-indirecthost-namecontactnamedhostforindirectXDMCP-portport-numUDPportnumbertosendmessagesto-onceTerminateserverafteronesession-classdisplay-classspecifydisplayclasstosendinmanage-cookiexdm-auth-bitsspecifythemagiccookieforXDMCP-displayIDdisplay-idmanufacturerdisplayIDforrequest-geometryWxHsetframebufferwidth&height-depthDsetframebufferdepth-pixelformatformatsetpixelformat(BGRnnnorRGBnnn)-udpinputportportUDPportforkeyboard/pointerdata-rfbportportTCPportforRFBprotocol-rfbwaittimemaxtimeinmstowaitforRFBclient-nocursordon't display a cursor-rfbauthpasswd-fileenableVNCpasswordauthentication-otpauthenableone-timepassword(OTP)authentication-pamauthenablePAMuser/passwordauthentication-noreversedisablereverseconnections-noclipboardsenddisableserver->clientclipboardsynchronization-noclipboardrecvdisableclient->serverclipboardsynchronization-nocutbuffersyncdisableclipboardsynchronizationforapplicationsthatusethe(obsolete)Xcutbuffer-idletimeoutSexitifSsecondselapsewithnoVNCviewerconnections-httpddirservefilesfromthespecifieddirectoryusingHTTP-httpportportportforHTTPserver-deferupdatetimetimeinmstodeferupdates(default40)-noflowcontrolwhencontinuousupdatesareenabled,sendupdateswhetherornottheclientisreadytoreceivethem-alrSenableautomaticlosslessrefreshandsettimertoSseconds(Sisfloatingpoint)-interframealwaysuseinterframecomparison-nointerframeneveruseinterframecomparison-economictranslatelessmemoryhungrytranslation-desktopnameVNCdesktopname(defaultx11)-alwayssharedalwaystreatnewclientsasshared-neversharednevertreatnewclientsasshared-dontdisconnectdon't disconnect existing clients when a new non-sharedconnectioncomesin(refusenewconnectioninstead)-viewonlyonlyletclientsviewtheremotedesktop-localhostonlyallowconnectionsfromlocalhost-interfaceipaddronlybindtospecifiedinterfaceaddress-ipv6enableIPv6support-inetdXvncislaunchedbyinetd-compatiblekbdsetMETAkey=ALTkeyasintheoriginalVNC-versionreportXvncversiononstderr
It is actually the exact output I get when launching vncserver, without the part I wrote in my first post.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, this was a legitimate bug in the vncserver script that occurred whenever the server was built without Java support. It has been fixed in the subversion repository, and you can check out a patched version from the stable branch by doing the following:
svn co svn://svn.code.sf.net/p/turbovnc/code/branches/1.2.x vnc
Let me know if you run into any further issues.
Last edit: DRC 2014-05-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First of all, thanks a lot for your help and your excellent reactivity =)
I've been able to successfully install turboVNC with your patched version,
but I don't think i am using it correctly.
I use vglconnect to connect to the server from the client.
I run vncserver from the ssh session. This gives me the display number to use later one
I run vglrun -d :display_number_obtained_earlier myopengl_program
when I do so, I get the following error message from vglrun:
Did I forget a step in the process?
I also noticed that when I run vglrun on a headless server (disabling gdm) I can't connect even on display :0 (vglrun with no argument). Is it normal?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, you need to install the TurboVNC Viewer on your client machine and then connect to the server display (your_machine:1 or whatever) using the TurboVNC Viewer. This gives you a remote desktop on the server machine. You can then open a shell within the remote desktop and run:
vglrun {application}
to launch a 3D application. You do not use vglconnect when using VirtualGL with an X proxy such as VNC, unless the X proxy and VirtualGL are running on different machines (they aren't in this case.) vglconnect is only used if you want to display VirtualGL using its internal image transport, which encodes only the 3D portion of the application's GUI as a video stream and sends the 2D portions of the GUI using regular remote X11 commands. In other words, with vglconnect, the 3D is rendered on the server, but the 2D is still rendered on the client. When using an X proxy, both 2D and 3D are rendered on the server.
The -d argument to vglrun specifies the display on which 3D rendering will take place. This is usually :0, because that's where the GPU is attached, so most people don't need to specify this argument (:0 is the default).
This is all very thoroughly documented in the VirtualGL and TurboVNC User's Guides.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the answer,
I actually tried that, but faced a problem that made me think I wasn't doing the right thing, which is why I tried with vglconnect:
When I connect turbovnc Viewer on the client machine to the turbovncserver, I get a gray window (very tight black and white meshing) with a clock on the top right corner, but no remote desktop, and I can't find a way to interact with it.
I attached a screenshot to illustrate my problem.
No wierd output from vncviewer though, as you can see.
That just means that the window manager isn't starting properly in the VNC session for some reason. Probably because Arch Linux is putting things in different paths than everyone else. Probably fixing that is going to require me to boot up Arch Linux in a virtual machine and see where it's storing things. If you have a working ~/.vnc/xstartup file from a different VNC flavor, however, then you should be able to copy it to ~/.vnc/xstartup.turbovnc and make TurboVNC do the same thing as the other VNC flavor. If you can get that to work, I'd be curious to see the contents of the working xstartup script.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok. I am exploring other leads anyway (c++ plugin in my program sending vertex, texture coordinates etc to an opengl remote client app), so no worries, I am not stuck yet =)
Keep me in touch
Last edit: Bruno Marques 2014-05-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Seems I'm running in to exactly the same problems on Arch and so if you ever do spin up that Arch VM to work out where the paths differ then I'd love to know. I'm extremely keen to try VirtualGL and TurboVNC on Arch.
Last edit: Rob Eastham 2014-06-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
VirtualGL: seems to work with no issues. Note that to get vglserver_config working, you have to install gdm and xauth.
TurboVNC: builds and runs with no problem, but since TurboVNC currently lacks the X Composite extension, it can't run Gnome 3 (even the "classic" mode checks for X Composite, although I don't think it actually uses it.)
Gnome runs in TigerVNC, but it's tortuously slow because of the lack of 3D acceleration (ideally, at some point, we'll be able to run these WM's in VirtualGL, but doing so is still very experimental at the moment. For instance, it isn't as simple as just doing 'vglrun gnome-session'.)
My suggestion for the moment is to use a more simplified window manager in VNC such as IceWM, which doesn't have compositing capabilities.
NOTE:
For both VGL and TurboVNC builds, you need to install the TurboJPEG wrapper for libjpeg-turbo (pacman -S turbojpeg), which installs libjpeg-turbo as a dependency. You can then pass -DTJPEG_LIBRARY=/usr/lib/libturbojpeg.so to cmake in order to use the system's version of TurboJPEG.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The version of Gnome in RHEL 7 is similar to the one in Arch Linux-- not quite as new but still new enough that it won't run without the X Composite extension. Moreover, unlike the Gnome implementation in Arch Linux, the one in RHEL 7 doesn't seem to want to run without 3D acceleration either. Thus, it won't run in any version of VNC, including the TigerVNC implementation that ships with RHEL 7.
KDE Plasma does, however, seem to work fine in both TurboVNC and TigerVNC, so if you can get KDE up and running in Arch Linux, that could be another workaround until I can look at the Gnome 3 issues in more detail.
Last edit: DRC 2014-07-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I am trying to use VirtualGL with TurboVNC on an Arch Linux machine, and I am experiencing some issues I hope you could help me to solve =)
I cannot get vncserver to start, this is my output:
I made a few unseccessful attempts to solve the problem, by reinstalling the xorg fonts, specify the -fp option with /usr/share/fonts/75dpi / 100dpi, uninstalling every packages I suspected could interfere with Turbovnc (vine vinagre, Tigervnc, etc) but couldn't get vncserver to run properly.
I've been told the problem could come from my distro, since some file locations on arch linux are quite unconventional...?
Hope you can help me =)
Can you post the contents of ~/.vnc/{hostname}-:1.log ?? There might be something revealing in there.
Here we go:
It is actually the exact output I get when launching vncserver, without the part I wrote in my first post.
Can you try editing vncserver and changing the following line:
to
? That will print out the arguments that vncserver is trying to pass to Xvnc, and hopefully I can see where that weird argument is coming from.
Last edit: DRC 2014-05-07
done:
I don't know if it is useful information, but I just checked and all the font, gdm/auth and .vnc/passwd paths specified here are valid
Last edit: Bruno Marques 2014-05-07
OK, this was a legitimate bug in the vncserver script that occurred whenever the server was built without Java support. It has been fixed in the subversion repository, and you can check out a patched version from the stable branch by doing the following:
Let me know if you run into any further issues.
Last edit: DRC 2014-05-07
First of all, thanks a lot for your help and your excellent reactivity =)
I've been able to successfully install turboVNC with your patched version,
but I don't think i am using it correctly.
I use vglconnect to connect to the server from the client.
I run vncserver from the ssh session. This gives me the display number to use later one
I run vglrun -d :display_number_obtained_earlier myopengl_program
when I do so, I get the following error message from vglrun:
Did I forget a step in the process?
I also noticed that when I run vglrun on a headless server (disabling gdm) I can't connect even on display :0 (vglrun with no argument). Is it normal?
No, you need to install the TurboVNC Viewer on your client machine and then connect to the server display (your_machine:1 or whatever) using the TurboVNC Viewer. This gives you a remote desktop on the server machine. You can then open a shell within the remote desktop and run:
to launch a 3D application. You do not use vglconnect when using VirtualGL with an X proxy such as VNC, unless the X proxy and VirtualGL are running on different machines (they aren't in this case.) vglconnect is only used if you want to display VirtualGL using its internal image transport, which encodes only the 3D portion of the application's GUI as a video stream and sends the 2D portions of the GUI using regular remote X11 commands. In other words, with vglconnect, the 3D is rendered on the server, but the 2D is still rendered on the client. When using an X proxy, both 2D and 3D are rendered on the server.
The -d argument to vglrun specifies the display on which 3D rendering will take place. This is usually :0, because that's where the GPU is attached, so most people don't need to specify this argument (:0 is the default).
This is all very thoroughly documented in the VirtualGL and TurboVNC User's Guides.
Thanks for the answer,
I actually tried that, but faced a problem that made me think I wasn't doing the right thing, which is why I tried with vglconnect:
When I connect turbovnc Viewer on the client machine to the turbovncserver, I get a gray window (very tight black and white meshing) with a clock on the top right corner, but no remote desktop, and I can't find a way to interact with it.
I attached a screenshot to illustrate my problem.
No wierd output from vncviewer though, as you can see.
That just means that the window manager isn't starting properly in the VNC session for some reason. Probably because Arch Linux is putting things in different paths than everyone else. Probably fixing that is going to require me to boot up Arch Linux in a virtual machine and see where it's storing things. If you have a working ~/.vnc/xstartup file from a different VNC flavor, however, then you should be able to copy it to ~/.vnc/xstartup.turbovnc and make TurboVNC do the same thing as the other VNC flavor. If you can get that to work, I'd be curious to see the contents of the working xstartup script.
I'll have to investigate further. In the meantime, TigerVNC works in a pinch. It just won't have the 3D-specific features that TurboVNC has.
Last edit: DRC 2014-05-13
Ok. I am exploring other leads anyway (c++ plugin in my program sending vertex, texture coordinates etc to an opengl remote client app), so no worries, I am not stuck yet =)
Keep me in touch
Last edit: Bruno Marques 2014-05-13
Seems I'm running in to exactly the same problems on Arch and so if you ever do spin up that Arch VM to work out where the paths differ then I'd love to know. I'm extremely keen to try VirtualGL and TurboVNC on Arch.
Last edit: Rob Eastham 2014-06-13
VirtualGL: seems to work with no issues. Note that to get vglserver_config working, you have to install gdm and xauth.
TurboVNC: builds and runs with no problem, but since TurboVNC currently lacks the X Composite extension, it can't run Gnome 3 (even the "classic" mode checks for X Composite, although I don't think it actually uses it.)
Gnome runs in TigerVNC, but it's tortuously slow because of the lack of 3D acceleration (ideally, at some point, we'll be able to run these WM's in VirtualGL, but doing so is still very experimental at the moment. For instance, it isn't as simple as just doing 'vglrun gnome-session'.)
My suggestion for the moment is to use a more simplified window manager in VNC such as IceWM, which doesn't have compositing capabilities.
NOTE:
For both VGL and TurboVNC builds, you need to install the TurboJPEG wrapper for libjpeg-turbo (pacman -S turbojpeg), which installs libjpeg-turbo as a dependency. You can then pass -DTJPEG_LIBRARY=/usr/lib/libturbojpeg.so to cmake in order to use the system's version of TurboJPEG.
More information on this:
The version of Gnome in RHEL 7 is similar to the one in Arch Linux-- not quite as new but still new enough that it won't run without the X Composite extension. Moreover, unlike the Gnome implementation in Arch Linux, the one in RHEL 7 doesn't seem to want to run without 3D acceleration either. Thus, it won't run in any version of VNC, including the TigerVNC implementation that ships with RHEL 7.
KDE Plasma does, however, seem to work fine in both TurboVNC and TigerVNC, so if you can get KDE up and running in Arch Linux, that could be another workaround until I can look at the Gnome 3 issues in more detail.
Last edit: DRC 2014-07-03
CORRECTION: KDE Plasma actually does work in both TigerVNC and TurboVNC. That was a user error on my part.
This is an old thread, but I wanted to post an update that GNOME 3 should now fully work with TurboVNC 2.1. See http://www.turbovnc.org/Documentation/Compatibility