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.
On 1/18/24 10:52 AM, DRC wrote:
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.On 1/17/24 5:14 PM, DRC wrote: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= gcalculatorIf that fixes the problem, then I can modify xstartup.turbovnc and make it unset that environment variable automatically.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 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 <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 turbovnc-user...@googlegroups.com. 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 turbovnc-users+unsubscr...@googlegroups.com. 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 turbovnc-users+unsubscr...@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 <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 turbovnc-users+unsubscr...@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.
