My apologies. I see now that you replied with the test report earlier
in the thread. So the session really is frozen, apparently. It might
be worth experimenting with the -rfbwait switch on the server. Try
setting it to a fairly low value, such as 500 ms, and see if the session
unfreezes in a reasonable period of time. I unfortunately have no
further ideas, since I can't reproduce that issue or the disconnect
issue. The only other suggestion I have is to do a debug build of
TurboVNC and attach GDB to the Xvnc process when it freezes. That will
at least tell you where it's hanging up.
On 2/17/21 3:13 PM, DRC wrote:
>
> I finally got a chance to test the TurboVNC Server on my Rock 960
> board. The cause of the GNOME 3 black screen was revealed by passing
> -verbose to /opt/TurboVNC/bin/vncserver:
>
> (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed
> (/usr/lib64/dri/swrast_dri.so: cannot open shared object file: No such
> file or directory)
> (EE) GLX: could not load software renderer
> (II) GLX: no usable GL providers found for screen 0
>
> The Mesa DRI drivers were installed, but our vncserver script didn't
> know to check for their existence under the system library paths used
> by Debian-based Arm Linux distributions (/usr/lib/aarch64-linux-gnu,
> etc.) That has been fixed.
>
> The "System policy prevents control of network connections" issue is
> easily reproducible and is apparently a known issue with using wi-fi
> networks on Ubuntu. It can be worked around by adding
> ";org.freedesktop.NetworkManager.network-control" to the Actions line
> in /etc/polkit-1/localauthority/50-local.d/45-turbovnc-gnome3.pkla.
> That will prevent the wi-fi settings applet (either GNOME 3 or MATE)
> from prompting you for a password when it launches, and adding
> ";org.freedesktop.NetworkManager.settings.modify.system" to the
> Actions line will prevent the wi-fi settings applet from prompting you
> for a password when editing the connection (although, in my testing,
> the applet still won't let you save any edits to the connection.) I
> don't have any interest in adding those permissions to TurboVNC's
> default PKLA file, because wi-fi isn't commonly used in TurboVNC
> hosts, and it isn't a great idea to edit network connections in a
> remote desktop session anyhow.
>
> I haven't been able to reproduce the other issues, so those may be
> specific to your hardware or network. I asked you to perform some
> simple tests when the TurboVNC Server freezes, but you never responded
> with the results of those tests. Those results will help me to better
> understand the issue, and I can't proceed without them.
>
> DRC
>
> On 12/17/20 4:45 PM, shen wrote:
>> Thanks a lot for your reply.
>>
>> "The network problem" means "System policy prevents control of
>> network connections" was disappeared with the help of a custom PKLA file.
>> And on Xfce4, when I clicked the network icon, the system reacts
>> already normally.
>>
>> But the disconnected problems like "Connection closed" and
>> "WriteExact: Socket error while running" *appear still often*.
>> And the sudden and irregular frozen problem of the TurboVNC
>> Server *exists always*.
>>
>> No problem, I'm not in a hurry. I'm a loyal TurboVNC-user ;)
>>
>> Best regards
>>
>> DRC schrieb am Montag, 14. Dezember 2020 um 18:50:41 UTC+1:
>>
>> I assume that "the network problem" means the problem whereby the
>> connection would disconnect sporadically, and "the TurboVNC
>> problem" means the problem whereby the TurboVNC Server would
>> freeze when launching Network Manager. Is that correct?
>>
>> If so, I am attempting to reproduce the issue. Several other
>> issues of that type were fixed by installing a custom PKLA file,
>> so it may be possible to fix this issue in the same way. Please
>> be patient, however, as I have a lot on my plate right now.
>>
>> DRC
>>
>> On 12/14/20 3:49 AM, shen wrote:
>>> The network problem, which is unrelated to the TurboVNC, has
>>> been fixed.
>>> But the TurboVNC problem exists still.
>>>
>>> The remote desktop connection through Xrdp works well on the
>>> Jetson Xavier, except that it runs with obvious delay, which is
>>> almost completely avoided by the TurboVNC.
>>>
>>> So I really don't want to give it up. Any suggestions?
>>>
>>> Best regards
>>>
>>> DRC schrieb am Dienstag, 8. Dezember 2020 um 18:24:45 UTC+1:
>>>
>>> When it freezes, try the following:
>>>
>>> 1. Disconnect and reconnect to the TurboVNC session. This
>>> will tell us
>>> whether the remote session is actually frozen or whether
>>> there is some
>>> issue with the viewer or the network layer.
>>>
>>> 2. If the session is still frozen after disconnecting and
>>> reconnecting,
>>> try logging into the server with SSH and running
>>>
>>> DISPLAY=:{n} xdpyinfo
>>>
>>> where {n} is the X display number of the session. This will
>>> tell us
>>> whether the actual TurboVNC X server is frozen.
>>>
>>> 3. If you are using the Windows native TurboVNC Viewer, try
>>> using the
>>> Windows/Java TurboVNC Viewer instead (or vice versa.) This
>>> will tell us
>>> whether the issue is specific to one of those viewer
>>> implementations.
>>> If the session is still frozen after Step 1, then restart it
>>> before
>>> trying to use the other viewer.
>>>
>>> 4. If you are using the Windows/Java TurboVNC Viewer with
>>> built-in TLS
>>> encryption enabled (which is the default), try disabling TLS
>>> encryption.
>>> This will tell us whether the issue is related to OpenSSL.
>>>
>>> 5. Check the server log
>>> (~/.vnc/{hostname}-{TurboVNC-display-number}.log) for any
>>> errors that
>>> might be occurring just prior to the freeze.
>>>
>>> 6. Try disabling the screen blanker in the TurboVNC session.
>>>
>>> On 12/8/20 10:57 AM, shen wrote:
>>> > Thanks a lot for your detailed explanation.
>>> >
>>> > I got still a black screen with the Unity and GNOME3 of
>>> the Jetson, no
>>> > matter how I set. So I gave up.
>>> > I installed MATE and xfce4 in the Jetson. The TurboVNC
>>> starts to work
>>> > successfully with the both.
>>> >
>>> > But another problem appears: After running well for a few
>>> minutes, the
>>> > remote desktop of the TurboVNC Viewer in Win10 freezes.
>>> > I tried many times with the both window managers, but the
>>> system turns
>>> > always into a frozen state.
>>> >
>>> > Best regards
>>> >
>>> >
>>> > DRC schrieb am Freitag, 4. Dezember 2020 um 19:14:02 UTC+1:
>>> >
>>> > Unfortunately, I cannot get Unity to launch from either
>>> GDM or
>>> > LightDM, and with no way of verifying whether that WM even
>>> works
>>> > without TurboVNC, it is impossible for me to fix whatever
>>> issues
>>> > might be preventing it from working with TurboVNC. GNOME
>>> 3 in
>>> > TurboVNC works fine for me on Ubuntu 18.04, so I'm not
>>> sure why it
>>> > isn't launching for you. You might try passing '-wm
>>> gnome-session'
>>> > to /opt/TurboVNC/bin/vncserver.
>>> >
>>> > If you don't want to use GNOME 3 in TurboVNC, I would
>>> suggest using
>>> > MATE as an alternative. It has a clean interface based on
>>> GNOME 2,
>>> > and it works well with Linux VNC servers.
>>> >
>>> > On 12/4/20 5:10 AM, shen wrote:
>>> >> Yes, I'm sure that I'm using Unity on Ubuntu18.04.
>>> >>
>>> >> I flashed my Jetson Xavier with JetPack 4.3 of NVIDIA:
>>> >> https://developer.nvidia.com/jetpack-43-archive
>>> >> https://www.jetsonhacks.com/2019/12/17/jetpack-4-3-release/
>>> >>
>>> >> The installed OS is Ubuntu18.04 and there are two DE
>>> (Unity7 and
>>> >> GNOME3), which can be selected while logging in:
>>> >> login.jpg
>>> >> I always choose the Unity, since I think not all the
>>> things run
>>> >> very well in this GNOME.
>>> >>
>>> >> It is mentioned in the docu of the TurboVNC that the
>>> TurboVNC
>>> >> server attempts to use OS specific techniques to launch
>>> the user's
>>> >> most recently used window manager:
>>> >>
>>> https://docs.oracle.com/cd/E19279-01/820-3257-12/turbovnc.html
>>> >> So I think the Unity on Ubuntu18.04 should be launched
>>> every time.
>>> >> I have also tried with the GNOME. The TurboVNC Viewer on
>>> Win10
>>> >> shows a black screen too.
>>> >>
>>> >> Besides, the Display Manager is *gdm3* at the moment. I
>>> don't know
>>> >> whether it has an influence or not.
>>> >>
>>> >> Best regards
>>> >>
>>> >>
>>> >> DRC schrieb am Donnerstag, 3. Dezember 2020 um 22:17:28
>>> UTC+1:
>>> >>
>>> >> That's a window manager issue, then. Are you really using
>>> >> Unity, which isn't installed by default on Ubuntu 18.04, or
>>> >> are you using the installed version of GNOME 3 that looks
>>> like
>>> >> Unity?
>>> >>
>>> >> On 12/3/20 2:21 PM, shen wrote:
>>> >>> Thanks a lot for your reply.
>>> >>>
>>> >>> Sorry I didn't describe my problem clearly.
>>> >>> I use the self-built TurboVNC Server in the Jetson Xavier
>>> >>> (aarch64, Ubuntu18.04, Unity) and the TurboVNC Viewer
>>> >>> (together with Putty) in Windows 10.
>>> >>> The TurboVNC Viewer in Win10 shows a black screen as
>>> follows:
>>> >>> black_screen_turbovnc_viewer_win10.JPG
>>> >>>
>>> >>> Best regards,
>>> >>> Shen
>>> >>>
>>> >>> DRC schrieb am Donnerstag, 3. Dezember 2020 um 19:47:12
>>> UTC+1:
>>> >>>
>>> >>> The value of DEBARCH for AArch64 Linux platforms may be
>>> >>> incorrect in the build system (I will double check), but
>>> >>> that is not related to the issue at hand.
>>> >>>
>>> >>> I'm not sure what you mean by "when I create a remote
>>> >>> desktop in Windows." TurboVNC can only be used to create
>>> >>> remote desktops on Linux/Unix systems. We only provide a
>>> >>> client (viewer) for Windows.
>>> >>>
>>> >>> If I misunderstood you and you are using the TurboVNC
>>> >>> Server on Linux/Unix, then tell me which window manager
>>> >>> you are trying to use. A black screen is typically due
>>> >>> to the window manager failing to start in the TurboVNC
>>> >>> Server session. Refer to
>>> >>> https://turbovnc.org/Documentation/Compatibility22 for a
>>> >>> list of window managers I have personally tested and
>>> >>> instructions for each.
>>> >>>
>>> >>> It is not necessary to use VirtualGL with TurboVNC.
>>> >>> VirtualGL is only necessary if you need GPU acceleration
>>> >>> for OpenGL applications running in a TurboVNC session.
>>> >>> TurboVNC can run OpenGL applications with software
>>> >>> rendering (Mesa) without the use of VirtualGL.
>>> >>>
>>> >>> DRC
>>> >>>
>>> >>> On 12/3/20 9:29 AM, shen wrote:
>>> >>>> Dear TurboVNC-Users,
>>> >>>>
>>> >>>> I built TurboVNC from source in my Jetson Xavier
>>> >>>> (aarch64) as follows:
>>> >>>>
>>> >>>> 1) build libjpeg-turbo:
>>> >>>> git clone
>>> https://github.com/libjpeg-turbo/libjpeg-turbo.git
>>> >>>> cd libjpeg-turbo && mkdir build && cd build
>>> >>>> cmake -G"Unix Makefiles"
>>> >>>> -DCMAKE_INSTALL_PREFIX=/opt/libjpeg-turbo ../
>>> >>>> make -j 8
>>> >>>> sudo make install
>>> >>>>
>>> >>>> 2) build turbovnc:
>>> >>>> git clone https://github.com/TurboVNC/turbovnc.git
>>> >>>> cd turbovnc && mkdir build && cd build
>>> >>>> cmake -G "Unix Makefiles" -DTVNC_BUILDJAVA=0 ../
>>> >>>> make -j 8
>>> >>>> sudo make install
>>> >>>>
>>> >>>> Besides:
>>> >>>>
>>> >>>> * I *didn't* change the following 2 things, since I
>>> >>>> think they are the same (or am I wrong?):
>>> >>>> o "DEBARCH=arm64" --> "DEBARCH=aarch64" in
>>> >>>> pkgsripts/makedpkg
>>> >>>> o "Architecture: arm64" --> "Archtecture: aarch64"
>>> >>>> in pkgsripts/deb-control
>>> >>>> * I didn't build and install VirtualGL in my Jetson
>>> >>>> Xavier, since a remote rendering is not necessary at
>>> >>>> the moment (or must TurboVNC always be used together
>>> >>>> with VirtualGL?)
>>> >>>>
>>> >>>>
>>> >>>> When I create a remote desktop in Windows, I got always
>>> >>>> a black screen.
>>> >>>> Where am I wrong and how should I solve the problem?
>>> >>>>
>>> >>>> Best regards,
>>> >>>> Shen
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> 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/8d28674d-52fb-46ef-b70f-313ab8b0ecb6n%40googlegroups.com
>>>
>>> >>>>
>>>
>>> <https://groups.google.com/d/msgid/turbovnc-users/8d28674d-52fb-46ef-b70f-313ab8b0ecb6n%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/3c54ed0c-79b2-4f12-9016-c14b16bf253an%40googlegroups.com
>>>
>>> >>>
>>>
>>> <https://groups.google.com/d/msgid/turbovnc-users/3c54ed0c-79b2-4f12-9016-c14b16bf253an%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/46af0490-426e-4618-b6c1-f0e40925676en%40googlegroups.com
>>>
>>> >>
>>>
>>> <https://groups.google.com/d/msgid/turbovnc-users/46af0490-426e-4618-b6c1-f0e40925676en%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
>>> > <mailto:turbovnc-user...@googlegroups.com>.
>>> > To view this discussion on the web visit
>>> >
>>>
>>> https://groups.google.com/d/msgid/turbovnc-users/e885f670-aa5e-457d-987d-2f78baa934d2n%40googlegroups.com
>>>
>>> >
>>>
>>> <https://groups.google.com/d/msgid/turbovnc-users/e885f670-aa5e-457d-987d-2f78baa934d2n%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/f1b947cc-101d-479c-9f86-53619dfb37ccn%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/turbovnc-users/f1b947cc-101d-479c-9f86-53619dfb37ccn%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/42805b56-61b2-49b0-90e2-1126a3d89f14n%40googlegroups.com
>> <https://groups.google.com/d/msgid/turbovnc-users/42805b56-61b2-49b0-90e2-1126a3d89f14n%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/b7ad69c2-2210-f3d4-f537-ccf2128801c7%40virtualgl.org.
