x11vnc is just a screen scraper. It doesn't render anything. It
attempts, as best as it can, to figure out when pixels have changed on
the X server to which it is attached, and it encodes and transmits those
pixels using the RFB protocol. Direct-rendered OpenGL, however, bypasses
the mechanisms that x11vnc uses to figure out when pixels have changed,
so x11vnc can't generally detect those changes.
As far as the illegal instruction failure, you may want to try various
combinations of setting/unsetting JSIMD_FORCENONE=1 in the environment
and passing -DTVNC_SYSTEMLIBS=0 or -DTVNC_SYSTEMLIBS=1 to cmake when
configuring the build. It occurred to me that we are using a
SIMD-accelerated zlib implementation as well. Passing
-DTVNC_SYSTEMLIBS=0 to the build will disable it and use the system's
zlib implementation (and the system's bzip2 and FreeType
implementations, so you'll need those dev kits installed as well.) If
that doesn't work, then I have no clue. You are very far outside of
the
scope of my support. Hopefully you can get away with disabling the
SIMD-accelerated zlib implementation but leaving SIMD acceleration
enabled in libjpeg-turbo. That would at least give you good performance
for the most common cases.
At this point, any further issues will need to be addressed on your end,
unless you can confirm that those issues affect TurboVNC on supported
platforms. Good luck.
DRC
On 5/23/21 2:05 PM, SugarRayLua wrote:
Thanks, again, DRC. That answers all of my questions, and yes, I meant
to say that all I needed was software-rendered OpenGL which x11vnc
that I was using didn’t seem to be able to render.
I did try to set the environment variable as you suggested. It didn’t,
however, remedy the illegal command. Here is the log with the
reference to the illegal instruction at the end (TurboVNC vncserver
running on Alpine Linux on iPad x86 emulator; Remoter VNC viewer
client app on same iPad connecting via local host):
iPad:/opt/TurboVNC/bin# cat /root/.vnc/iPad:1.log
TurboVNC Server (Xvnc) 32-bit v2.2.6 (build 20210521)
Copyright (C) 1999-2021 The VirtualGL Project and many others (see
README.txt)
Visit http://www.TurboVNC.org for more information on TurboVNC
23/05/2021 11:53:44 Using security configuration file
/opt/TurboVNC/etc/turbovncserver-security.conf
23/05/2021 11:53:44 Enabled security type 'tlsvnc'
23/05/2021 11:53:44 Enabled security type 'tlsotp'
23/05/2021 11:53:44 Enabled security type 'tlsplain'
23/05/2021 11:53:44 Enabled security type 'x509vnc'
23/05/2021 11:53:44 Enabled security type 'x509otp'
23/05/2021 11:53:44 Enabled security type 'x509plain'
23/05/2021 11:53:44 Enabled security type 'vnc'
23/05/2021 11:53:44 Enabled security type 'otp'
23/05/2021 11:53:44 Enabled security type 'unixlogin'
23/05/2021 11:53:44 Enabled security type 'plain'
23/05/2021 11:53:44 Desktop name 'TurboVNC: iPad:1 (root)' (iPad:1)
23/05/2021 11:53:44 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
23/05/2021 11:53:44 Listening for VNC connections on TCP port 5901
23/05/2021 11:53:44 Interface 0.0.0.0
23/05/2021 11:53:44 Framebuffer: BGRX 8/8/8/8
23/05/2021 11:53:44 New desktop size: 1240 x 900
23/05/2021 11:53:44 New screen layout:
23/05/2021 11:53:44 0x00000040 (output 0x00000040): 1240x900+0+0
23/05/2021 11:53:44 Maximum clipboard transfer size: 1048576 bytes
23/05/2021 11:53:44 VNC extension running!
XFree86-Bigfont extension: shmget() failed, size = 790528, Function
not implemented
XFree86-Bigfont extension: shmget() failed, size = 790528, Function
not implemented
XFree86-Bigfont extension: shmget() failed, size = 790528, Function
not implemented
XFree86-Bigfont extension: shmget() failed, size = 790528, Function
not implemented
XFree86-Bigfont extension: shmget() failed, size = 790528, Function
not implemented
XFree86-Bigfont extension: shmget() failed, size = 790528, Function
not implemented
XFree86-Bigfont extension: shmget() failed, size = 790528, Function
not implemented
XFree86-Bigfont extension: shmget() failed, size = 790528, Function
not implemented
23/05/2021 11:54:15 Got connection from client 127.0.0.1
23/05/2021 11:54:15 Could not enable TCP corking: Invalid argument
23/05/2021 11:54:15 Using protocol version 3.8
23/05/2021 11:54:15 Could not disable TCP corking: Invalid argument
23/05/2021 11:54:15 Full-control authentication enabled for 127.0.0.1
23/05/2021 11:54:15 Pixel format for client 127.0.0.1:
23/05/2021 11:54:15 16 bpp, depth 15, little endian
23/05/2021 11:54:15 true colour: max r 31 g 31 b 31, shift r 10 g 5 b 0
23/05/2021 11:54:15 Using tight encoding for client 127.0.0.1
23/05/2021 11:54:15 rfbProcessClientNormalMessage: ignoring unknown
encoding 9 (9)
23/05/2021 11:54:15 rfbProcessClientNormalMessage: ignoring unknown
encoding -65527 (ffff0009)
23/05/2021 11:54:15 Interframe comparison enabled
23/05/2021 11:54:15 Using JPEG subsampling 0, Q86 for client 127.0.0.1
23/05/2021 11:54:15 Enabling X-style cursor updates for client 127.0.0.1
23/05/2021 11:54:15 Enabling cursor position updates for client 127.0.0.1
23/05/2021 11:54:15 rfbProcessClientNormalMessage: ignoring unknown
encoding -131072 (fffe0000)
23/05/2021 11:54:15 Enabling Desktop Size protocol extension for
client 127.0.0.1
23/05/2021 11:54:15 Enabling LastRect protocol extension for client
127.0.0.1
23/05/2021 11:54:15 rfbProcessClientNormalMessage: ignoring unknown
encoding -131071 (fffe0001)
23/05/2021 11:54:15 rfbProcessClientNormalMessage: ignoring unknown
encoding -131070 (fffe0002)
23/05/2021 11:54:15 rfbProcessClientNormalMessage: ignoring unknown
encoding -131069 (fffe0003)
23/05/2021 11:54:15 Using Tight compression level 2 for client 127.0.0.1
23/05/2021 11:54:15 Using 2 threads for Tight encoding
(EE) Illegal instruction at address 0x56879339
(EE)
Fatal server error:
(EE) Caught signal 4 (Illegal instruction). Server aborting
(EE) (EE)
Illegal instruction at address 0x56879339
(EE)
FatalError re-entered, aborting
(EE) Caught signal 4 (Illegal instruction). Server aborting
(EE)
xterm: fatal IO error 11 (Resource temporarily unavailable) or
KillClient on X server ":1"
xterm: fatal IO error 11 (Resource temporarily unavailable) or
KillClient on X server ":1"
Fyi
On Sunday, May 23, 2021 at 7:38:28 AM UTC-7 DRC wrote:
However, when I actually started to try and use TurboVNC, I could
start vncserver, but when I tried to connect from a client, it
would not finish connecting and the log file indicated the
connection aborted due to some illegal commands. I suspect that
actually might be a problem with the x86 emulator running the
Alpine Linux (as it is known to not be able to yet run all Linux
programs)
If the emulator doesn’t have full support for various x86 SIMD
instruction sets, then that could explain it. Try setting
JSIMD_FORCENONE=1 in the environment to turn off SIMD acceleration
in libjpeg-turbo, but understand that that will reduce the
performance of the TurboVNC Server dramatically.
1) connect remotely to TurboVNC vncserver with any VNC viewer
(i.e. not just TurboVNC vncviewer)? I want to be able to do so
since I’m aiming to use TurboVNC to allow me to see Linux 3D
graphics on my iPad Alpine LInux emulator which the server is on
does not have 3D graphics capabilities itself (so VirtualGL won’t
helP) and the viewer client is a separate app on my iPAD that is
not a Linux device (i.e. I couldn’t install TurboVNC vncviewer on it)
Yes. Refer to the TurboVNC User’s Guide for compatibility notes.
Generally, any VNC viewer will work, but only VNC viewers that
support the TightVNC decoder with TurboVNC’s optimizations and the
RFB flow control extensions will perform optimally in all cases.
Currently, that includes only the TurboVNC and TigerVNC Viewers.
2) view 3D graphics (eg openGL graphics) originating from the
linux TurboVNC vncserver headless host given as I mentioned above
that the headless host does not have any means to render 3D
graphics (i.e. no ability to connect directly from the LInux
server to the iPAD’s graphic system) and no link from the iPad’s
separate non-Linux VNC viewer to render 3D graphics from the
viewer itself. My understanding is that the TurboVNC program is
the only VNC program that can software render 3D graphics coming
from the VNC server and convert such graphics to a 2D image to
then send and be displayed on the VNC non-linux, non 3D graphics
viewer. If I am mistaken in this ability of TurboVNC’s then, I
will not ask you further for assistance in trying to get this to
work for my needs and the needs of the iSH Linux x86 emulator
community (it may still be useful for the larger Alpine LInux
community though as you helped me show that it at least can be
built on that distribution).
“view 3D graphics (eg openGL graphics) originating from the
linux
TurboVNC vncserver headless host” is awkward terminology, so I
don’t quite understand your meaning there. If you mean that
you
want to remotely display the output of the TurboVNC host’s
graphics card/GPU, then no, TurboVNC cannot do that. TurboVNC
creates one or more virtual X servers on demand, and those virtual
X servers are not connected to the host’s graphics hardware
(VirtualGL is used to establish that connection for the purpose of
enabling GPU acceleration for OpenGL.) If software-rendered OpenGL
is all you need, however, then the TurboVNC Server does support
that. It is not the only VNC server that supports that, however.
TigerVNC does too, although their server is generally a lot harder
to build.
I appreciate your further thoughts and time; I’ve learned a lot
more about Linux, cmake, make and X from trying to build this on
my machine.
Sincerely,
On Friday, May 21, 2021 at 3:15:26 PM UTC-7 DRC wrote:
I just noticed that, earlier, you tried to do:
make CFLAGS=-D_GNU_SOURCE
That won't work with CMake-generated Makefiles, because CMake
populates the compiler flags in the Makefiles whenever it
generates the build. Try instead:
cd {build-directory}
rm -rf CMake*
cmake {any-other-CMake-args-you-need}
-DCMAKE_C_FLAGS="-D_GNU_SOURCE -D__GLIBC__" {source-directory}
make
NOTE: 'rm -rf CMake*' clears any cached build state. Doing
that isn't necessary with a fresh build directory, nor is it
necessary when rebuilding. I only suggested it above in
order to make 100% sure that the new compiler flags are
applied, because I can't remember how aggressively CMake
caches those.
If that doesn't work, then I will repeat my advice to look at
the X.org X server package for Alpine and see what they did
to make it build. X.org also requires __GLIBC__ to be defined
in features.h.
To answer your question about __GLIBC__, there are other
places within the TurboVNC Server code that check for
__GLIBC__ to be defined, so it's best to define both
__GLIBC__ and _GNU_SOURCE.
DRC
On 5/21/21 3:44 PM, SugarRayLua wrote:
Thanks, DRC.
I do have glibc and its headers installed. I found
features.h in the usr/include directory and printed its code
as follows:
iPad:/usr/include# cat ./features.h
#ifndef _FEATURES_H
#define _FEATURES_H
#if defined(_ALL_SOURCE) && !defined(_GNU_SOURCE)
#define _GNU_SOURCE 1
#endif
#if defined(_DEFAULT_SOURCE) && !defined(_BSD_SOURCE)
#define _BSD_SOURCE 1
#endif
#if !defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE) \
&& !defined(_XOPEN_SOURCE) && !defined(_GNU_SOURCE) \
&& !defined(_BSD_SOURCE) && !defined(__STRICT_ANSI__)
#define _BSD_SOURCE 1
#define _XOPEN_SOURCE 700
#endif
#if __STDC_VERSION__ >= 199901L
#define __restrict restrict
#elif !defined(__GNUC__)
#define __restrict
#endif
#if __STDC_VERSION__ >= 199901L || defined(__cplusplus)
#define __inline inline
#elif !defined(__GNUC__)
#define __inline
#endif
#if __STDC_VERSION__ >= 201112L
#elif defined(__GNUC__)
#define _Noreturn __attribute__((__noreturn__))
#else
#define _Noreturn
#endif
#endif
Sorry about my continued linux knowledge limit but is
defining _GNU_SOURCE 1 the same as defining _GLIBC_ as you
suggested? If so, then will let the Alpine Linux support
know what you’ve said and wait to see if they can offer any
further suggestions.
If my features.h file doesn’t define _GLIBC_ could I modify
the file myself to define it? I realize that it is a header
file and part of an important library of core code so may
not be a good idea. However, I’m not running any critical
files on my linux install, and if the Alpine Linux support
thought it might work by adding a definition to that file,
I’d be willing to try it.
What do you think?
Sincerely,
On Friday, May 21, 2021 at 9:42:10 AM UTC-7 DRC wrote:
I assume you also have the glibc development
headers/library installed? If so, then
/usr/include/features.h should exist, and that header
should define __GLIBC__. If it doesn't, then that's
also a distribution-specific issue.
If you have the glibc development headers/library
installed and the build is still failing, then I'm
clueless. The TurboVNC build system detects glibc in
exactly the same way that the (autotools-based) X.org
build system does. Thus, the X.org Alpine package may
have faced similar difficulties, and it may be
instructive to look at that package and see how they
worked around them.
glibc is a documented requirement of the TurboVNC Server
on Linux. Even if we were able to work around this
specific compatibility issue with musl, there are many
others that would pop up.
DRC
On 5/20/21 4:13 PM, SugarRayLua wrote:
Thanks, DRC.
If I am understanding your instructions correctly, I do
not think _GNU_SOURCE is defined on the command line
that builds access.c:
“
Building C object
unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o
cd /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os
&& /usr/bin/cc -DCLIENTIDS -DCOMPOSITE -DDAMAGE
-DDPMSExtension -DGLXEXT -DHASXDMAUTH -DHAS_SHM
-DHAVE_DIX_CONFIG_H -DHAVE_SHA1_IN_LIBSHA1
-DHAVE_XSHMFENCE -DIPv6 -DMITSHM -DMONOTONIC_CLOCK
-DNVCONTROL -DPANORAMIX -DPRESENT -DRANDR -DRENDER
-DRES -DSCREENSAVER -DSHAPE -DTCPCONN -DTURBOVNC
-DUNIXCONN -DUSE_POLL -DXACE -DXCSECURITY -DXDMCP
-DXF86BIGFONT -DXFIXES -DXINPUT -DXRECORD -DXTEST -DXV“
Alpine Linux uses musl although I do have glib also
installed.
Is there any simple instructions you could offer for me
to modify CMakeFile or my Make build to enable
_GNU_SOUCE? I’ve tried make CFLAGS=-D_GNU_SOURCE but
that doesn’t work. As a novice user, I don’t have the
knowledge to do any other changes myself.
I’ll write the Alpine Linux support also to see if
there is anything they can suggest.
Thanks for your continued efforts to help.
Sincerely
On Wednesday, May 19, 2021 at 7:26:04 AM UTC-7 DRC wrote:
I think this is also a distribution-specific
issue. I verified that my build is using the same
code path in access.c that your build is using.
If
sys/socket.h defines SO_PEERCRED, then access.c
will try to use 'struct ucred'. (NOTE: access.c is
X.org code, not TurboVNC code.) However, 'struct
ucred' is apparently only defined if _GNU_SOURCE is
defined, so the first thing I would do is 'make
VERBOSE=1' and verify whether _GNU_SOURCE is
defined on the command line that builds access.c.
If it isn't, then it's probably because this build
system check failed:
https://github.com/TurboVNC/turbovnc/blob/main/unix/Xvnc/CMakeLists.txt#L4-L9
<https://github.com/TurboVNC/turbovnc/blob/main/unix/Xvnc/CMakeLists.txt#L4-L9>,
which would happen if features.h doesn't define
__GLIBC__ on your system. It could also be that,
for whatever reason, your system doesn't define
'struct ucred'.
On 5/15/21 9:36 PM, SugarRayLua wrote:
Thanks again for your continued help.
If I am understanding you correctly, no, I did not
make the build with adding the switch
“TVNC_SYSTEMX11=1”) if that was what your were
asking (i.e. just did “make”)
Here is the relevant debug output again but with
make VERBOSE=1:
[ 84%] Built target sync
make -f
unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build.make
unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/depend
make[2]: Entering directory '/root/turbovnc-2.2.6'
cd /root/turbovnc-2.2.6 && /usr/bin/cmake -E
cmake_depends "Unix Makefiles"
/root/turbovnc-2.2.6
/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os
/root/turbovnc-2.2.6
/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os
/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/DependInfo.cmake
--color=
make[2]: Leaving directory '/root/turbovnc-2.2.6'
make -f
unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build.make
unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build
make[2]: Entering directory '/root/turbovnc-2.2.6'
[ 84%] Building C object
unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o
cd
/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os
&& /usr/bin/cc -DCLIENTIDS -DCOMPOSITE -DDAMAGE
-DDPMSExtension -DGLXEXT -DHASXDMAUTH -DHAS_SHM
-DHAVE_DIX_CONFIG_H -DHAVE_SHA1_IN_LIBSHA1
-DHAVE_XSHMFENCE -DIPv6 -DMITSHM -DMONOTONIC_CLOCK
-DNVCONTROL -DPANORAMIX -DPRESENT -DRANDR -DRENDER
-DRES -DSCREENSAVER -DSHAPE -DTCPCONN -DTURBOVNC
-DUNIXCONN -DUSE_POLL -DXACE -DXCSECURITY -DXDMCP
-DXF86BIGFONT -DXFIXES -DXINPUT -DXRECORD -DXTEST
-DXV -I/root/turbovnc-2.2.6/unix/include
-I/root/turbovnc-2.2.6/unix/Xvnc/X_include
-I/root/turbovnc-2.2.6/common/zlib
-I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/Xext
-I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/include
-I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/miext/damage
-I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/present
-I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/../../lib/pixman/pixman
-I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/../render
-I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/../../../lib/libsha1
-w -O3 -DNDEBUG -fno-strict-aliasing -o
CMakeFiles/os.dir/access.c.o -c
/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c
/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c:
In function 'GetLocalClientCreds':
/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c:1178:18:
error: storage size of 'peercred' isn't known
1178 | struct ucred peercred;
| ^~~~~~~~
make[2]: ***
[unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build.make:96:
unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o]
Error 1
make[2]: Leaving directory '/root/turbovnc-2.2.6'
make[1]: *** [CMakeFiles/Makefile2:2834:
unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/all]
Error 2
make[1]: Leaving directory '/root/turbovnc-2.2.6'
make: *** [Makefile:150: all] Error 2
On Saturday, May 15, 2021 at 5:05:14 PM UTC-7 DRC
wrote:
Can you rerun with
make VERBOSE=1
? I need to see which include directories are
being passed to the compiler, because it seems
as if one of the in-tree X.org headers isn’t
being picked up (or are you using TVNC_SYSTEMX11?)
On May 15, 2021, at 4:46 PM, SugarRayLua
<meaning...@gmail.com> wrote:
Ok, thanks.
Here is what I believe is the most verbose
debugging of the relevant part of the make
where the build stopped:
Pruning file
'unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/flags.make'.
Finished prerequisites of target file
'unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o'.
Must remake target
'unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o'.
Putting child 0x565bb320
(unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o)
PID 674 on the chain.
Live child 0x565bb320
(unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o)
PID 674
[ 84%] Building C object
unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o
Reaping winning child 0x565bb320 PID 674
Live child 0x565bb320
(unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o)
PID 675
/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c:
In function 'GetLocalClientCreds':
/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c:1178:18:
error: storage size of 'peercred' isn't known
1178 | struct ucred peercred;
| ^~~~~~~~
Reaping losing child 0x565bb320 PID 675
make[2]: ***
[unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build.make:96:
unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o]
Error 1
Removing child 0x565bb320 PID 675 from chain.
Reaping losing child 0x565d3d60 PID 673
make[1]: *** [CMakeFiles/Makefile2:2834:
unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/all]
Error 2
Removing child 0x565d3d60 PID 673 from chain.
Reaping losing child 0x565ac240 PID 522
make: *** [Makefile:150: all] Error 2
Removing child 0x565ac240 PID 522 from chain.“
Please let me know if you need more information.
Sincerely,
On Saturday, May 15, 2021 at 5:04:43 AM UTC-7
DRC wrote:
Please post the full text of the error so
I can see where it is occurring. Build
errors are never very meaningful without
context.
On May 15, 2021, at 12:50 AM,
SugarRayLua <meaning...@gmail.com> wrote:
Hello, again, TurboVNC Community,
I’m still trying to build TurboVNC for
Alpine Linux x86 from downloaded
tarball. I managed to get cmake to work
successfully and got through 84% of the
make build before I got an “in function
‘GetLocalClientCreds’ error = storage
size of ‘peercred’ isn’t known error”.
I’m still a Linux novice and searched
the web for other users who encountered
that error and most said that setting
either the CFLAGS or CPPFLAGS variable
to “-D_GNU_SOURCE” (e.g. make
CFLAGS=-D_GNU_SOURCE) allowed the make
build to compile. However, setting
neither flag fixes the problem and
allows the make build for me.
Does anyone have any other suggestions?
I appreciate any assistance anyone could
offer.
Thanks and have a good night.
--
You received this message because you
are subscribed to the Google Groups
"TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop
receiving emails from it, send an email
to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/797b6ea1-993a-4e5e-a718-d6f47b94379dn%40googlegroups.com
<https://groups.google.com/d/msgid/turbovnc-users/797b6ea1-993a-4e5e-a718-d6f47b94379dn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are
subscribed to the Google Groups "TurboVNC
User Discussion/Support" group.
To unsubscribe from this group and stop
receiving emails from it, send an email to
turbovnc-user...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/ac661251-a0ef-4606-9ba2-a934692d4224n%40googlegroups.com
<https://groups.google.com/d/msgid/turbovnc-users/ac661251-a0ef-4606-9ba2-a934692d4224n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are
subscribed to the Google Groups "TurboVNC User
Discussion/Support" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
turbovnc-user...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/01f07e12-e2ea-40db-9a95-d5ba1c962addn%40googlegroups.com
<https://groups.google.com/d/msgid/turbovnc-users/01f07e12-e2ea-40db-9a95-d5ba1c962addn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to
the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
turbovnc-user...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/08f243f1-58bf-4799-9df9-3d2d28f7c0d7n%40googlegroups.com
<https://groups.google.com/d/msgid/turbovnc-users/08f243f1-58bf-4799-9df9-3d2d28f7c0d7n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the
Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/18137fd8-d832-479d-960a-18fa2cb7a786n%40googlegroups.com
<https://groups.google.com/d/msgid/turbovnc-users/18137fd8-d832-479d-960a-18fa2cb7a786n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the
Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/78975d38-d828-4605-b9db-e85f6b2c590en%40googlegroups.com
<https://groups.google.com/d/msgid/turbovnc-users/78975d38-d828-4605-b9db-e85f6b2c590en%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to turbovnc-users+unsubscr...@googlegroups.com
<mailto:turbovnc-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/9fd18102-40d5-4eaf-94d3-a34eef721b38n%40googlegroups.com
<https://groups.google.com/d/msgid/turbovnc-users/9fd18102-40d5-4eaf-94d3-a34eef721b38n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "TurboVNC
User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to turbovnc-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/caeb4364-f368-b629-f3a6-0028ce45fa2c%40virtualgl.org.
