1 second delay in partial terminal window update using VGL.

[marioroy]

Thank you for TurboVNC with VirtualGL capabilities.

Unfortunately, enabling useVGL causes issues with Gnome Terminal. The last line isn't updated until 1 second later. Sometimes, the cursor is partially drawn and completed drawing 1 second later. The worst is the one second lag (randomly) for keyboard input, from the time the keyboard is pressed to the character fully displayed inside the terminal.

Server: TurboVNC 3.0.3 NVIDIA Driver 530.30.02 NVIDIA Graphics RTX 3070 Clear Linux OS (Release 38630) GNOME Version 43.3 Windowing System X11

Client: macOS Big Sur 11.7.3 (Intel) TurboVNC 3.0.3

Client: The same behavior occurs running vncviewer on Clear Linux.

I filed a bug ticket at Clear Linux due to xkbcomp failing. Otherwise, TurboVNC works great after making the 3 symbolic links.

I will try another NVIDIA driver release (starting with 525, 520, 510).

The rest is off-topic, in the event someone wants to try TurboVNC on Clear Linux.

There used to be regular live desktop image ISOs. See the steps here for making a functional live desktop USB.

Using NVIDIA graphics? See automation for installing the NVIDIA driver. This requires booting the live USB into text mode by pressing the letter e at the boot menu. Prepend "3 " with a space to the list of kernel arguments. Instructions are provided on the screen for running the installer. Install the OS to a different USB drive.

I installed TurboVNC using the RPM path. You will need the package-utils bundle. There are issues with the RPM embedded script not supporting Clear Linux. So, the --noscripts option is specified.

sudo swupd bundle-add package-utils x11-server x11-tools
sudo rpm -ivh --noscripts --nodeps turbovnc-3.0.3.x86_64.rpm

# To uninstall
sudo rpm -e --noscripts turbovnc

I installed VirtualGL-3.1, obtained from the web.

sudo rpm -ivh --nodeps VirtualGL-3.1.x86_64.rpm

# To uninstall
sudo rpm -e VirtualGL

[marioroy]

The bottom of the terminal window is not refreshed after exiting man ls. Random occurrence.

[marioroy]

There is a one second delay before the last line (Manual page ls...) is drawn. Also, random occurrence.

[marioroy]

The one-second delay (randomly) for screen updates is awkward, using VGL. I tested NVIDIA driver 510.08.03, 525.89.02, 530.30.02, and 530.41.03.

Non-VGL works fantastic.

[marioroy]

Wandering Pixel does not work in GNOME 43.3, something I wanted to try. The issue goes away if I run glxgears in the background. I changed the TVNC_VGLRUN line in xstartup.turbovnc to the following, to limit the fps.

TVNC_VGLRUN="vglrun +wm +sync -sp -fps 60 -np 2

[dcommander]

Another user reported a different but possibly related issue (#362) with GNOME Terminal, VGL, and TurboVNC, but I was unable to reproduce it, and it went away with the latest nVidia driver. In attempting to reproduce that issue, I did not observe this issue either. Since Clear Linux isn't officially supported by TurboVNC, it is incumbent upon the user community to diagnose the issue. There is very little I can do about it unless the issue is reproducible on a supported platform. I test about a dozen different Linux distributions in my lab using VMWare, including a couple (openSUSE Leap and Fedora) that aren't officially supported, but I can only test the nVidia drivers on CentOS and Rocky.

[marioroy]

Next, I tried Fedora 37. Here, the problem is worst running VGL.

turbovnc-3.0.3-20230227.x86_64 VirtualGL-3.1-20230315.x86_64

I clicked on the Terminal icon, but no terminal is displayed.

[marioroy]

I tried TurboVNC on Ubuntu 20.04.6 LTS (Focal Fossa). TurboVNC without the vncserver -vgl option works fine. Running with -vgl is problematic in this OS as well.

Client testing running vncviewer on the same machine.

1. turbovnc_3.0.3_amd64.deb
2. virtualgl_3.1_amd64.deb
3. NVIDIA driver 515.86.01
4. GNOME version 3.36.8
5. Windowing system X11
6. Kernel 5.15.0-67-lowlatency

I moved the window around, which refreshed the TurboVNC window. I tried again: man ls. Notice the line "do not ignore entries starting with" partially drawn.

I exited the man page. The last line is not cleared.

Edit: All is fine vgl and non-vgl running vncviewer on the mac, remote-desktop to Ubuntu 20.04.6.

[dcommander]

What do you mean "all is fine"? You mean that you no longer see the issue, or you don't see the issue with that specific viewer?

[marioroy]

For Ubuntu 20.04.6 and Fedora 37, I tested initially using vncviewer on the same machine where running vncserver -vgl or vncserver. I connected to 127.0.0.1:1 or :2 respectively.

I later ran the TurboVNC / Viewer 3.0.3 application on the Mac (connecting remotely to Ubuntu) and gnome-terminal ran fine, no issues using VirtualGL.

Of the 3 Linux distributions, running with -vgl is broken on Fedora 37. I was unable to get the gnome-terminal window to appear.

[dcommander]

OK, now you seem to be describing multiple issues. I need to understand exactly which symptoms are observed with which configurations. Please specify the client/server configurations with which you observe:

1. The issue whereby GNOME Terminal does not appear at all when run with VirtualGL
2. The issue whereby characters typed into GNOME Terminal (when run with VGL) appear only after a delay

I have not observed either issue, so you're going to have to help me figure out exactly which component is failing on which platform.

Also, if you are using any non-default TurboVNC settings, then please disclose them. Also please tell me the approximate latency and bandwidth of your network.

[marioroy]

For all three OS platforms tested, I installed TurboVNC 3.0.3 and VirtualGL 3.1 with default settings. The network is Wi-Fi on the Mac. No issues with network bandwidth (~ 54MB). The server host is connected via wire using 1 Gigabit interface to the same router (~ 95+ MB).

1. The issue whereby GNOME Terminal does not appear is on Fedora Linux 37. I tested vncviewer on the same box (locally) to 127.0.0.1:2 including on the Mac connecting remotely to 192.168.1.34:2. VGL appears broken, unusable.

2. The issue whereby characters typed into GNOME Terminal (when run with VGL) appearing after 1 second delay occurs on Clear Linux (yes, I know not officially supported) running vncviewer locally to 127.0.0.1:1 and from the Mac connecting remotely to 192.168.1.34:1. The issue also occurs on Ubuntu 20.04.6 running vncviewer locally on the same box connecting to 127.0.0.1:1. Locally, referring to running on the same box where vncserver is running.

The only time I have experienced success with VGL is running VNC viewer on the Mac connecting remotely 192.168.1.34:1 to Ubuntu 20.04.6.

There's a warning running vncserver on Fedora 37 stating unable to connect to :1, already used by X11 (some .X11-unix socket file exist in /tmp). So, it automatically selects :2. To get VGL to work, I needed to pass the -d :2 option to vglrun inside the xstartup script.

In all 3 OS tested { Clear Linux, Fedora Linux 37, and Ubuntu 20.04.6 }, non-VGL works great. No issues at all and simply amazing. BTW, I connected directly, no tunneling during testing. The SSH tunneling is something I tried subsequently getting audio to work. So amazing really. Youtube video is smooth and no hiccups to audio. Even holding down the backspace in GNOME terminal emits beeps until releasing the backspace. There are no gaps or hiccups to audio.

I have never seen anything so fast and smooth until trying TurboVNC. Great work.

I also tried OpenCL and CUDA displaying hundreds of Mandelbrot images automatically. It works with/non VGL which is great. I hadn't realize that VGL isn't needed to run OpenCL/CUDA on the GPU. I also ran glxspears64 VGL/non-VGL mainly to witness the effect of running VGL.

I'm hoping that all is clear now, nothing left out. All defaults, except on Fedora 37 needing -d :2 to vglrun.

[marioroy]

A workaround for Clear Linux (running vncserver -vgl) is changing the GNOME Terminal size in preference from the default 80x24 to 80x25. I'm unable to reproduce the issue with terminal sizes 80x25 ~ 80x28. YMMV

# VGL options in xstartup.turbovnc
TVNC_VGLRUN="vglrun +wm -sp -fps 60"

[dcommander]

OK, but that doesn't solve the issue, so I'm not sure why you closed it.

[marioroy]

I felt bad for any time lost, especially when Clear Linux and Fedora 37 are not in official supported list. Though, the issue may creep up in the next major supported list distribution.

[dcommander]

For all three OS platforms tested, I installed TurboVNC 3.0.3 and VirtualGL 3.1 with default settings. The network is Wi-Fi on the Mac. No issues with network bandwidth (~ 54MB). The server host is connected via wire using 1 Gigabit interface to the same router (~ 95+ MB).

1. The issue whereby GNOME Terminal does not appear is on Fedora Linux 37. I tested vncviewer on the same box (locally) to 127.0.0.1:2 including on the Mac connecting remotely to 192.168.1.34:2. VGL appears broken, unusable.
2. The issue whereby characters typed into GNOME Terminal (when run with VGL) appearing after 1 second delay occurs on Clear Linux (yes, I know not officially supported) running vncviewer locally to 127.0.0.1:1 and from the Mac connecting remotely to 192.168.1.34:1. The issue also occurs on Ubuntu 20.04.6 running vncviewer locally on the same box connecting to 127.0.0.1:1. Locally, referring to running on the same box where vncserver is running.

The only time I have experienced success with VGL is running VNC viewer on the Mac connecting remotely 192.168.1.34:1 to Ubuntu 20.04.6.

There's a warning running vncserver on Fedora 37 stating unable to connect to :1, already used by X11 (some .X11-unix socket file exist in /tmp). So, it automatically selects :2. To get VGL to work, I needed to pass the -d :2 option to vglrun inside the xstartup script.

Referring to the User's Guide, the -d option to vglrun (or the VGL_DISPLAY environment variable) should point to the X server that is attached to the GPU (the "3D X server"), not to the TurboVNC X server (the "2D X server".) If you log in locally to the machine on which VirtualGL is being used, then the 3D X server will be :1, and that is what you should pass to vglrun -d. If that machine is sitting at the display manager login prompt, then the 3D X server will be :0 (assuming that vglserver_config has been used to configure the machine.)

[marioroy]

Sir, thank you. I miss-read the vglrun help usage. Sure enough, defaulting to :0.0 is the clue along with mentioning DRI. I recalled momentarily puzzled at the time, because wrongly assuming the number matching vncserver.

-d <d>    : <d> = the X display/screen or DRI device to use for 3D rendering
           [default = :0.0]

On Fedora 37, the (-d :1) option is needed as vglrun will not run without it. The reason is that /tmp/.X11-unix/X1 exists and running vncserver emits a warning. Ditto for the warning without the (-vgl) option.

$ ./vncserver -vgl

WARNING: fedora-pc:1 is taken because of /tmp/.X11-unix/X1
Remove this file if there is no X server fedora-pc:1

Desktop 'TurboVNC: fedora-pc:2 (mario)' started on display fedora-pc:2

It seems that vglrun does not know to use (-d :1) on its own without manual intervention. I removed the (-d :1) option to capture the log. The session exits immediately.

xstartup.turbovnc: Executing vglrun +wm /etc/X11/xinit/Xsession "/usr/bin/gnome-session"
Killing Xvnc process ID 6463

New testing:

Fedora 37 (vncserver -vgl) exhibits the same 1 second delay issue/behaviour seen on Clear Linux. The workaround, changing the height of the terminal window to 80x25 resolves the issue (vncviewer on the mac, remote connection to the Fedora box).

TVNC_VGLRUN="vglrun +wm -d :1"

Note: The workaround 80x25 using vncviewer on Fedora (same box), connecting locally to 127.0.0.1:2, does not work. The 1 second delay or unfinished refresh persists. Same as on Clear Linux including Ubuntu when using vncserver -vgl and vncviewer on the same box.