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.
Am 18.01.2024 um 22:12 schrieb 'DRC' via TurboVNC User Discussion/Support:
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.On 1/18/24 3:58 PM, Torsten Kupke wrote: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).Am 18.01.2024 um 21:19 schrieb 'DRC' via TurboVNC User Discussion/Support: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 On 1/16/24 2:22 PM, Torsten Kupke wrote: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 tkansgarAm 05.01.2024 um 00:41 schrieb 'DRC' via TurboVNC User Discussion/Support: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.On Tuesday, January 2, 2024 at 9:42:46 PM UTC-5 DRC wrote: 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.) On 1/2/24 6:29 PM, DRC wrote: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. On 1/2/24 3:16 PM, Torsten Kupke wrote: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 Am 02.01.2024 um 20:45 schrieb 'DRC' via TurboVNC User Discussion/Support:-- You received this message because you are subscribed to theFurther 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. On Tuesday, December 19, 2023 at 1:40:38 PM UTC-5 DRC wrote: 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 On 12/19/23 12:40 PM, Torsten Kupke wrote: > 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 >-- You received this message because you are subscribed to theGoogle Groups "TurboVNC User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/2e98ca31-b6d8-4971-bc59-1f1edf5f508en%40googlegroups.com <https://groups.google.com/d/msgid/turbovnc-users/2e98ca31-b6d8-4971-bc59-1f1edf5f508en%40googlegroups.com?utm_medium=email&utm_source=footer>.Google Groups "TurboVNC User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/0a67d17c-9453-4b4e-841e-f9598acee91b%40t-online.de <https://groups.google.com/d/msgid/turbovnc-users/0a67d17c-9453-4b4e-841e-f9598acee91b%40t-online.de?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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/88998028-d2b1-4e34-82f5-db1c69ea9b99n%40googlegroups.com <https://groups.google.com/d/msgid/turbovnc-users/88998028-d2b1-4e34-82f5-db1c69ea9b99n%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/f773c5c7-e600-4462-9302-184a12e2f57b%40t-online.de <https://groups.google.com/d/msgid/turbovnc-users/f773c5c7-e600-4462-9302-184a12e2f57b%40t-online.de?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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/5de31aba-d995-0620-2662-73fde0aeb852%40virtualgl.org <https://groups.google.com/d/msgid/turbovnc-users/5de31aba-d995-0620-2662-73fde0aeb852%40virtualgl.org?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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/e45ebf4d-8a5c-414e-b317-63cc693e996b%40t-online.de <https://groups.google.com/d/msgid/turbovnc-users/e45ebf4d-8a5c-414e-b317-63cc693e996b%40t-online.de?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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/15ba54ab-3b03-0062-9d46-53028348bf5c%40virtualgl.org <https://groups.google.com/d/msgid/turbovnc-users/15ba54ab-3b03-0062-9d46-53028348bf5c%40virtualgl.org?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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/0415e628-71b2-4dd2-8ee8-d25936dbfc5c%40t-online.de.
