Cannot connect locally to TVNC 3.1 on Ubuntu 22.04

[tkan...@t-online.de]

Hi,

 

yesterday I upgraded my Ubuntu workstation from version 18.04 via 20.04 to 22.04. Firstly I proceeded using the TVNC server 2.2.7, and detected, when locally connecting to the running TVNC session, that its desktop was transparently overlayed over the native desktop. Of course, the viewer window also was displayed showing its toolbar and the usual desktop content. Today I installed TVNC 3.1 replacing TVNC 2.2.7.Now, when I try to connect locally (viewer and server running on the same machine), firstly I get the expected window "New TurboVNC Connection" displaying the local hostname in the VNC server field. When clicking connect, I get the window "SSH Password for <MY USERNAME>@<WORKSTATION NAME>" (with the real names) showing my username in the appropriate field. When entering my password, I get the next expected window "TurboVNC Session Manager" showing the X display name of the (obviously already running) TVNC session <WORKSTATION NAME>:1 nearby the buttons "Connect", "New OTP", "View-only" and "Kill". When clicking "Connect" I get the attached error message. What can I do to fix this? Is it really necessary to use a one-time password? Or can I simply use my own normal password as before?

 

BR

tkansgar



[DRC]

You don't have to use the TurboVNC Session Manager.  Both the TurboVNC User's Guide and the "New TurboVNC Connection" dialog itself explain that, if you enter a TurboVNC host into the "VNC server" field without specifying a VNC display number, the TurboVNC Viewer will start the TurboVNC Session Manager for that host.  The TurboVNC Session Manager is a "secure by default" solution, so it uses SSH for encryption and authenticates using a one-time password passed through the SSH tunnel.  If, however, you want to connect directly to a TurboVNC session without using the TurboVNC Session Manager, then you have to specify the VNC display number (e.g. localhost:1 or localhost:0).  TurboVNC 2.2.x and prior (and other VNC solutions, such as TigerVNC) assume Display :0 if the VNC display number isn't specified, but TurboVNC 3.0.x and later assume that you want to use the TurboVNC Session Manager if the VNC display number isn't specified.

As to why the TurboVNC Session Manager is failing, Ubuntu 22.04 and other modern Linux distributions use X Display :1 for the primary X server (which is often Xwayland running on top of a Wayland session) after you log in locally.  Apparently something happened that caused /tmp/.X11-unix/X1 to be deleted, so the vncserver script didn't know that the primary X server was using Display :1, and it tried to use that display number itself.  Xvnc didn't actually start, because the Unix domain socket for Display :1 was already bound, and /opt/TurboVNC/bin/vncpasswd erroneously tried to obtain an OTP from the primary X server.  I think the correct way to fix that is to modify vncserver so that it tries to listen on a Unix domain socket for a particular display number before assuming that the display number is available.  (Referring to https://github.com/TurboVNC/turbovnc/pull/42, another user tried to get me to integrate a similar patch years ago, but the issue they were experiencing was a lot more esoteric, and I could never reproduce it.)  In the meantime, however, you should be able to work around that issue by logging out and back in again, which should restore /tmp/.X11-unix/X1.  After /tmp/.X11-unix/X1 is restored, the TurboVNC Server will choose Display :2 for the TurboVNC session.

As far as why the VNC desktop was overlaid on the native desktop, that could have also been related to the aforementioned problem.  When Xvnc failed, the vncserver script still tried to start the window manager.  (I need to examine why Xvnc didn't return an error code that caused the vncserver script to abort.)  Since the vncserver script creates a unique DBus instance, perhaps the window manager you are using was able to install two copies of itself on the same display.

Anyhow, I have a couple of legitimate issues to look into, but hopefully that gives you enough information to work around the issues.

DRC

 --
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/1702986179015.1374600.9e23d95d935780794dc2db9af331b3d4f54e88a2%40spica.telekom.de.

[Torsten Kupke]

Hi CRC,

Am 19.12.2023 um 16:41 schrieb 'DRC' via TurboVNC User Discussion/Support:
> Apparently something happened that caused /tmp/.X11-unix/X1 to be
> deleted, so the vncserver script didn't know that the primary X server
> was using Display :1, and it tried to use that display number itself.

Maybe I have another explantion for this: I have a .vnc file stored on
that machine specifying "port=5901". I think, the viewer found this file
and therefore tried to connect to the XServer :1. Could this be the
case? So if :1 now is in use by the native XServer, I simply would have
to specify "port=5902" in my .vnc file. Can you agree? Would this solve
my issue?

However, I'm on Christmas vacation now. So I will need a proper solution
not before 2nd of Jan. '24.

Merry Christmas and a happy new year for you and all other readers!

tkansgar

[Torsten Kupke]

Sorry: CRC -> DRC

[DRC]

No, by deleting /tmp/.X11-unix/X1, I was able to exactly reproduce the
issue you reported with the Session Manager.  That error occurred when
the Session Manager tried to start a new TurboVNC session through SSH. 
In order for Port=5901 to have any effect, it would either have to be
specified in the default TurboVNC connection info file
(~/.vnc/default.turbovnc), or it would have to be specified in another
connection info file (either a TightVNC-compatible connection info file,
which has a .vnc extension, or a TurboVNC connection info file, which
has a .turbovnc extension) that you pass to the TurboVNC Viewer on the
command line.  Otherwise, the mere existence of such a connection info
file on the machine wouldn't matter.  Also, the error occurred prior to
the TurboVNC Viewer attempting to establish the RFB connection with the
TurboVNC Server, so the viewer had not yet used the value of the Port
parameter.

DRC

[DRC]

Further information regarding this issue:

With the default GDM configuration, there is no X server active on the login screen, because the GDM greeter is using Wayland.  When you log in, either Xwayland or Xorg (depending on whether you chose a Wayland or an Xorg session) is started on Display :0, so there is no possibility of a conflict with TurboVNC.  However, if you use vglserver_config in VirtualGL to configure the host for use with VirtualGL's GLX back end, vglserver_config will disable Wayland in GDM.  That causes the GDM greeter to use Xorg rather than Wayland, and the greeter's Xorg instance listens on Display :0.  Thus, VirtualGL can use the greeter's X server to access the GPU while the host is sitting at the login prompt.

On hosts configured thusly (with WaylandEnable=false in GDM's custom.conf file), a conflict occurs if you start a TurboVNC session while the host is sitting at the login prompt, then you log in locally.  When you start a TurboVNC session while the host is sitting at the login prompt, TurboVNC (rightfully) chooses Display :1 for the session, because nothing is using the resources associated with Display :1.  However, if you then log in locally, GDM starts a second Xorg instance for the local session (so as not to conflict with the greeter's Xorg instance.)  GDM indiscriminately chooses Display :1 for the local session without checking whether something else is already using the resources associated with Display :1.  Thus, it effectively stomps all over the TurboVNC session that is listening on Display :1.  That causes the problems that you observed.

I can (and will) make the vncserver script more robust, in the sense that it will check whether an abstract socket for a display number is in use before deciding to use that display number.  However, GDM needs to do likewise.

The only apparent workarounds for this are:

1. If you have used vglserver_config to configure a host for use with VirtualGL's GLX back end, then be very cautious when logging in locally.  That is true irrespective of TurboVNC, because logging in locally on such a host will cause GDM to suspend the greeter's X server, which has the effect of causing any applications currently running with VirtualGL to freeze.  Use '/opt/TurboVNC/bin/vncserver -list' to ensure that no TurboVNC sessions are listening on :1 before you log in locally, and avoid local logins if at all possible.

2. Comment out 'WaylandEnable=false' in /etc/gdm3/custom.conf, and restart GDM.  This is not true of all modern Linux systems, but with Ubuntu 22 at least, GDM will continue to start an Xorg instance at the login prompt even though the greeter is using Wayland.  You can set VGL_DISPLAY=:1024 to use that Xorg instance as a 3D X server with VirtualGL's GLX back end.

I'm also going to investigate whether it might be possible for VirtualGL to play more nicely with Wayland on modern Linux distributions.

[Torsten Kupke]

Hi DRC,

for me this issue is resolved in the meanwhile. I managed the relevant files on the remote host to start TuboVNC's X Server for display :2 and therefore with port 5902. And for both TuboVNC viewers (on the remote host too and on my Windows PC at home) I did the same. That works perfectly. So I wouldn't need an improvement regarding this.

And no, I don't use VirtualGL. The remote host is my workstation (owned by my employer), where I do my daily work. For my job I have no need to use OpenGL (or VirtualGL).

But I have some other new issues with TuboVNC, which I will report in the next days (when I have some time to write the mail(s)).

BR

transgar

--

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/2e98ca31-b6d8-4971-bc59-1f1edf5f508en%40googlegroups.com.

[DRC]

I don't know why the issue occurred in the first place, then, unless for some reason your employer also disabled Wayland in /etc/gdm3/custom.conf.  Regardless, I'm glad you were able to find a workaround for your particular use case.  I did notice that, on my Rocky Linux 8 box, the greeter always starts Xorg on Display :0 regardless of the value of WaylandEnable.  Maybe Ubuntu 22 can behave that way as well, under certain circumstances.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/0a67d17c-9453-4b4e-841e-f9598acee91b%40t-online.de.

[DRC]

Oof.  Apparently I already filed the issue as a bug against RHEL, and Red Hat rejected it.

https://bugzilla.redhat.com/show_bug.cgi?id=1673793

But since the issue also occurs in Ubuntu, maybe I should've filed it against GDM.

(I realize that the issue is resolved from your POV.  I am just updating this thread in case someone finds it via Google.  Apparently I answer so many bug reports that I can't remember the ones I myself filed two years ago, so the person who finds this thread via Google may be me.)

[DRC]

For completeness, I discovered a workaround to the issue, which is passing '-listen local' to /opt/TurboVNC/bin/vncserver.  Apparently GDM will not stomp on Display :1 if TurboVNC is listening on both the abstract and pathname Unix domain sockets associated with that display.  Passing '-listen local' causes TurboVNC to listen on the abstract UDS.  Note, however, that there are security concerns with abstract UDSs, so maybe not a good idea on production systems.

[Torsten Kupke]

Hi DRC,

unfortunately I have to proceed this thread. When working locally again on the machine running the TVNC server 3.1 on Ubuntu 22.04, I detected, that some windows of applications provided with Ubuntu (at least the calculator and the system log) and started from within the locally running TVNC client are still overlaid on the native desktop. When the client is in fullscreen mode, they are completely hidden and become only visible, when the client leaves the fullscreen mode. And then again I can see the only icon residing on the desktop (called "Home") twice with a small diagonal offset between both. However, inside the TVNC client window that icon is visible a third time (which is expected in this case).

Very annoying is the fact, that mostly (sometimes there are exceptions) it is not possble to activate those windows by simply clicking into them. Instead I have to click onto the icon representing those windows in the dock bar to be able to work with them. And then, when I want to proceed my work inside the TVNC client, I have to click onto its icon in the dock bar of the local session. Simply clicking into the TVNC client instead does nothing. I think, this behaviour has to do with the overlaid desktop. So my question would be, whether it's possible to avoid displaying it and showing those application windows only inside the TVNC client, when started inside (as it was under Ubuntu 18.04).

Apart from this, when I start those applications from within the TVNC client running on my home PC, I can see their windows also in fullscreen mode.

BR

tkansgar

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/88998028-d2b1-4e34-82f5-db1c69ea9b99n%40googlegroups.com.

[DRC]

Can you verify whether the WAYLAND_DISPLAY environment variable is set in the TurboVNC session?  That could be the cause.  If you started the TurboVNC session from a shell in the local (Wayland) session, then the TurboVNC session may have picked up the WAYLAND_DISPLAY environment variable, and that may have caused certain applications running in the TurboVNC session to display to the local (Wayland) session rather than to the TurboVNC (X11) session.

Try unsetting WAYLAND_DISPLAY when you run the applications in the TurboVNC session, e.g.

    WAYLAND_DISPLAY= gcalculator

If that fixes the problem, then I can modify xstartup.turbovnc and make it unset that environment variable automatically.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/f773c5c7-e600-4462-9302-184a12e2f57b%40t-online.de.

[DRC]

I cannot make a TurboVNC session run simultaneously with a local Wayland session at all.  Thus, I can't reproduce the circumstances under which you observe the issue below.  On Ubuntu 20.04, Ubuntu 22.04, and Rocky 9, if I attempt to start a TurboVNC session while a local Wayland session is active, the window manager in the TurboVNC session immediately fails, and the failure screen is displayed on the Wayland session rather than in the TurboVNC session.  This is true regardless of whether I attempt to start the TurboVNC session from the local Wayland session or from an SSH session, so it has nothing to do with environment variables.

Thus, I need you to describe exactly how you are starting the local and TurboVNC sessions, and in what order.  That will hopefully allow me to understand how to reproduce the issue.  I may have misunderstood that you were using a local Wayland session rather than Xorg.  I will reiterate that it is difficult to collate such information from multiple simultaneous bug reports on a mailing list.

[DRC]

Never mind.  I am able to reproduce the issue by starting the TurboVNC session first, then logging in locally with a Wayland session.  Once the local Wayland session is logged in, gnome-calculator (as an example) will always display to the Wayland session, even if it is started in the TurboVNC session.

Setting GDK_BACKEND=x11 fixes the issue for GNOME-specific applications, such as the calculator, and it also fixes the issue whereby I could not start a GNOME/TurboVNC session while a local Wayland session was active.  However, I still cannot start a TurboVNC session from within the local Wayland session.  I have to start the TurboVNC session from an SSH session.  I am still investigating, so stand by.

[DRC]

This should now be fixed in the latest 3.1.x pre-release build of the server (https://turbovnc.org/DeveloperInfo/PreReleases).  Please upgrade the TurboVNC package on your Linux host and re-test.  Also let me know if you observe any other applications that try to display to the local Wayland session instead of the TurboVNC session.  I verified that Qt applications don't do that, but other applications might.  xstartup.turbovnc now unsets WAYLAND_DISPLAY, for good measure, as well as setting GDK_BACKEND=x11.

Also, vncserver now warns if you try to start a TurboVNC session while WAYLAND_DISPLAY is set.  Starting a TurboVNC session with GNOME will generally fail from within a local Wayland session.  However, because of the aforementioned GDK_BACKEND fix, it should now be possible to start a TurboVNC session with GNOME from an SSH session if a local Wayland session is active.  Also, starting a TurboVNC session with an X11-only window manager (MATE, Xfce, GNOME Flashback, etc.) should work from within a local Wayland session.

DRC

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/f773c5c7-e600-4462-9302-184a12e2f57b%40t-online.de.

[Michael D. Setzer II]

On 18 Jan 2024 at 11:45, 'DRC' via TurboVNC User
Discussion/Suppor wrote:

Date sent: Thu, 18 Jan 2024 11:45:07 -0500
Subject: Re: [TurboVNC-Users] Cannot connect locally to TVNC
3.1 on Ubuntu 22.04
From: "'DRC' via TurboVNC User Discussion/Support"
<turbovn...@googlegroups.com>
To: turbovn...@googlegroups.com
Organization: The VirtualGL Project
Send reply to: turbovn...@googlegroups.com

>
> Never mind. I am able to reproduce the issue by starting the TurboVNC session first, then
> logging in locally with a Wayland session. Once the local Wayland session is logged in,
> gnome-calculator (as an example) will always display to the Wayland session, even if it is
> started in the TurboVNC session.
> Setting GDK_BACKEND=x11 fixes the issue for GNOME-specific applications, such as the
> calculator, and it also fixes the issue whereby I could not start a GNOME/TurboVNC session
> while a local Wayland session was active. However, I still cannot start a TurboVNC session
> from within the local Wayland session. I have to start the TurboVNC session from an SSH
> session. I am still investigating, so stand by.
>

Just wondering? With the wayland and later gnome on Fedora, I
always had issues with trying to run a local vnc connection with
tigervnc. I've had no problems using XFCE. Seems the wayland
and gnome 3 don't like multiple logins.
In /etc/sysconfig/tvncservers have this ## is port number.
VNCSERVERS="##:msetzerii"
VNCSERVERARGS[##]="-wm xfce"

> again on the machine running theTVNC server 3.1 on Ubuntu 22.04, I

> theremote host too and on my Windows PC at home) I did the same.

> https://groups.google.com/d/msgid/turbovnc-users/0a67d17c-9453-4b4
> e-841e-f9598acee91b%40t-online.de.

>
> --
> 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/88998028-d2b1-4e3
> 4-82f5-db1c69ea9b99n%40googlegroups.com.

> --
> 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/f773c5c7-e600-4462
> -9302-184a12e2f57b%40t-online.de.

>
> --
> 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/ac405f57-435c-d2ac-
> bfda-4025b8007f37%40virtualgl.org .


+------------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor (Retired)
mailto:mi...@guam.net
mailto:mset...@gmail.com
mailto:mset...@gmx.com
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[Torsten Kupke]

I will test it. But unfortunately I won't be able to do that, until I go back to the office to work directly on the workstation. At the moment, I can't say when that will be. Please be patient! When working remotely, all windows are shown inside the TVNC session (as I wrote).

But one question: Where could I find that warning about starting the TVNC session, while WAYLAND_DISPLAY is set? Will it be in the logfile stored in ~/.vnc?

By the way: The TVNC session is started automatically at boot time for me. You had explained me some years ago, how this can be achieved. But of course, the TVNC client is started inside the local session, which may be Wayland. The local session in turn is started in the default way provided by Ubuntu 22.04 (through gdm I think).

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/5de31aba-d995-0620-2662-73fde0aeb852%40virtualgl.org.

[DRC]

On 1/18/24 3:51 PM, Michael D. Setzer II wrote:
>> Never mind. I am able to reproduce the issue by starting the TurboVNC session first, then
>> logging in locally with a Wayland session. Once the local Wayland session is logged in,
>> gnome-calculator (as an example) will always display to the Wayland session, even if it is
>> started in the TurboVNC session.
>> Setting GDK_BACKEND=x11 fixes the issue for GNOME-specific applications, such as the
>> calculator, and it also fixes the issue whereby I could not start a GNOME/TurboVNC session
>> while a local Wayland session was active. However, I still cannot start a TurboVNC session
>> from within the local Wayland session. I have to start the TurboVNC session from an SSH
>> session. I am still investigating, so stand by.
> Just wondering? With the wayland and later gnome on Fedora, I
> always had issues with trying to run a local vnc connection with
> tigervnc. I've had no problems using XFCE. Seems the wayland
> and gnome 3 don't like multiple logins.
> In /etc/sysconfig/tvncservers have this ## is port number.
> VNCSERVERS="##:msetzerii"
> VNCSERVERARGS[##]="-wm xfce"

I assume you mean TurboVNC and not TigerVNC.  I just verified that the
same issue we have been discussing on Ubuntu 22.04 existed on Fedora as
well and is now fixed in the latest pre-release build.

[DRC]

To clarify, the issue should not be dependent on where you are connecting from.  However, it is dependent on whether you are logged into a local Wayland session on the host or not.  If the local session is logged out when you connect remotely, then that would explain why you don't observe the issue.

Also, I don't understand why you can't upgrade the TurboVNC package remotely via SSH.

The warning will be displayed to the command line.  WAYLAND_DISPLAY will never be set if you start the TurboVNC session at boot time, so that warning is irrelevant in that case.  I did not add the warning specifically for your use case.  I added it because I noticed another issue in the context of testing the issue you reported.  In the interest of thoroughness and openness, I discuss all related issues that are fixed at the same time as the reported issue, because this is an open conversation that many people may read.

It doesn't matter if you start the TurboVNC Viewer from a local Wayland session.  It only matters if you start the TurboVNC Server from a local Wayland session.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/e45ebf4d-8a5c-414e-b317-63cc693e996b%40t-online.de.

[Torsten Kupke]

Yes, of course, the local session is always logged out, when I go to home. It makes no sense for me to keep it alive, because I'm very seldom in the office sitting in front of the workstation. And from home I only need the running TVNC session, but not the local one. And so if I would test it remotely, I couldn't say, whether that issue is fixed, because in this case all windows (also the calculator window) were visible inside the TVNC session. So it makes no sense to test it remotely. And then I prefer to install the new prerelease, when I'm back in the office the next time. Currently I'm thinking of going to the office next Tuesday, but I cannot promise it. So I'm very sorry, that you have to wait some time for my feedback.

I now wonder, why this issue (which seems to be related to Wayland) happens, when Wayland doesn't matter, when starting the TVNC session at boot time.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/15ba54ab-3b03-0062-9d46-53028348bf5c%40virtualgl.org.

[DRC]

There are two related issues.

Issue 1:
The issue you reported is that GTK applications will display to the local GNOME/Wayland session if a local GNOME/Wayland session is active.  That happens regardless of how the TurboVNC session is started.  GTK somehow detects a running GNOME/Wayland session irrespective of whether WAYLAND_DISPLAY is set, and it uses Wayland if it detects a running GNOME/Wayland session.  That had the effect of redirecting GTK applications running in a TurboVNC session to the local session instead.  Thus, xstartup.turbovnc now sets GDM_BACKEND=x11 to force GTK applications running in a TurboVNC session to use X11 (as opposed to auto-detecting whether they should use Wayland or X11.)

Issue 2:
The issue I observed was that I could not, under any circumstances, start a TurboVNC session from a local Wayland session.  That is related to Issue 1, because GNOME is also a GTK application.  Thus, when I attempted to start a GNOME/TurboVNC session from a local Wayland session, effectively gnome-session tried to start a second instance of GNOME on a Wayland display that already had an instance of GNOME.  Unsurprisingly, that failed.  Even with the GDM_BACKEND fix mentioned above, GNOME still fails in TurboVNC if you try to start GNOME/TurboVNC from a local Wayland session, but it now works if you start GNOME/TurboVNC from an SSH session while a Wayland session is running simultaneously.

Whether or not you start a TurboVNC session from a local Wayland session matters for Issue 2.  It doesn't matter for Issue 1.  And where you start the viewer doesn't matter for either issue.  The reason you didn't observe Issue 1 remotely is because the local Wayland session was not running.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/0415e628-71b2-4dd2-8ee8-d25936dbfc5c%40t-online.de.

[Torsten Kupke]

Hi DRC,

I was in the office today, verified again, that the issue still is present with the official release 3.1 and then installed the last prerelease 3.1.1. And yes, the issue is fixed now! All windows of any GNOME applications started inside the TVNC session are displayed in the TVNC client window, which was started in the local (probably Wayland) session.

And I have to correct myself: The Home icon, which was visible twice on the local desktop with TVNC 3.1, was not visible a third time inside the TVNC client window, as I wrote before. That was a false memory on my part. Now with the prerelease it's still visible twice, but one inside the TVNC client window.

So all is fine now, and I'm happy again with TurboVNC. Many thanks again for your work!

BR

tkansgar

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/f16c2767-caad-0214-0d99-f2c74b1ae724%40virtualgl.org.

[DRC]

Excellent.  Thanks for testing.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/7554171f-c04e-447d-b8e2-bcaf88f64bb0%40t-online.de.