Distorted graphics in Gnome-Terminal

[thetomcorp]

When running a VGL enabled TurboVNC session periodically Gnome-Terminal has distorted visuals. The text/cursor shows up as a box, and is slow to refresh, placing the cursor over the area will eventually trigger a refresh.

OS: Rocky Linux 8.6 TurboVNC Server: 3.0.2 TurboVNC Client: 2.2.3 and 3.0.1 and 3.0.2 (all windows) Nvidia Driver: 510.73.08 CUDA Version: 11.6 Nvidia Card: Tesla T4 VirtualGL: 3.0.2

The issue appears to only happen when using Gnome-Terminal when the entire gnome-classic desktop is run with VGL enabled. it most often happens after the TurboVNC client is resized from the original resolution. This did not occur with the same hardware using CentOS 7.5 with Nvidia Driver Version: 440.64.00 CUDA Version: 10.2 and TurboVNC 2.2.3

This also doesn't occur when using Xpra with vglrun gnome-terminal which is why I'm submitting to TurboVNC instead of VirtualGL.

[dcommander]

Try upgrading the server to 3.0.3. This sounds like another symptom of an RFB flow control bug that was fixed in 7e7ff2fcb33f84fdbb99618e00f3c0d3ffa74ebf.

[thetomcorp]

I have upgraded to 3.0.3 and still find the same problem. My tests with 3.0.3 have been under low latency and without any network interruptions. This will happen in both the TurboVNC client and with noVNC web client. I've gone back and tested with TurboVNC 3.0 Server as well and still finding the issue.

[dcommander]

To clarify, when you said that the issue didn't occur with TurboVNC 2.2.3, you meant the TurboVNC 2.2.3 Server? Is there any way you could test the TurboVNC 2.2.x server on your Rocky Linux machine? (NOTE: Copy /opt/TurboVNC/bin/xstartup.turbovnc to ~/.vnc/xstartup.turbovnc before you uninstall TurboVNC 3.0.x. That is probably necessary in order to make the window manager work properly with TurboVNC 2.2.x, since TurboVNC 2.2.x didn't support RHEL 8 derivatives.)

If you can't reproduce the issue with TurboVNC 2.2.x on Rocky Linux 8, then that means the issue is caused by something that was introduced in TurboVNC 3.0.x. If you can reproduce the issue with TurboVNC 2.2.x on Rocky Linux 8, then that means the issue is caused by something that was introduced in Rocky Linux 8 (and which VirtualGL may not be handling properly.)

[thetomcorp]

I'm running into the same issue with 2.2.7 server on Rocky 8. There is a considerable amount of differences between our old setup on CentOS 7 and Rocky 8. The hardware has remained the same but all versions of the software/os/drivers have changed.

The problem seems to only be noticeable in Gnome-Terminal and not in Xterm, Gedit or Firefox. I did more testing with TurboVNC Server 3.0.3. I launched the desktop without vgl enabled, then ran 'vglrun gnome-terminal' and don't appear to have the issue. It looks like this only occurs on Rocky 8 when the entire gnome-classic desktop is run with $useVGL enabled and not when vglrun is used gnome-terminal.

[dcommander]

Thanks for testing. I'll try to reproduce, now that the scope of the issue has been narrowed down.

[dcommander]

I tried reproducing your setup as closely as I could (Rocky Linux 8.7, nVidia 510.108.03, VirtualGL 3.0.2, TurboVNC 3.0.2 Server, Windows TurboVNC 3.0.2 Viewer), but unfortunately I cannot reproduce the issue. I tried running the GNOME Classic desktop with both the GLX and EGL back ends in VirtualGL. I also tried starting the TurboVNC session without VirtualGL and running GNOME Terminal using vglrun +wm (which is what TurboVNC does when you pass -vgl to it.)

[thetomcorp]

I moved the latest nvidia driver and the problem appears to have gone away. ¯_(ツ)_/¯

Thank you for looking into it. It looks as if the problem was with that particular release of the NVIDIA driver.