search

TurboVNC / turbovnc

Main TurboVNC repository
https://TurboVNC.org
GNU General Public License v2.0
761 stars 138 forks source link

gnome menu disappears when any user physically starts a graphics session from gdm on the machine #282

Closed jsfrancal closed 3 years ago

jsfrancal commented 3 years ago

Hello,

First of all thanks for this great tool!

I have a problem using TurboVNC v2.2.6 (with Virtualgl 2.6.5 enabled with -vgl) on a Ubuntu 18.04 LTS machine, using the default gnome desktop and gdm.

  1. When no user is physically logged onto the machine, there is no problem, the tool works as expected when I launch a server and connect to it with a client.

  2. However if I as a user, or any other valid unix user, happens to be already logged on with a graphics session (the default gnome) physically on the machine when the Turbovnc server is started, the Turbovnc successfully establishes a graphics connexion and opens a window, but the window shows only the background desktop image and no gnome menu; it is also impossible to right click to obtain a menu dialog. The session is thus unusable.

  3. More awkward, if I start from state 1. with a functional TurboVNC session, and a user then logs onto the machine with a graphics session while I'm using my TurboVNC session, then the gnome menu bars instantly disappear from it and I am left only with the background image again, back to state 2. If the "physical" user then logs off, nothing changes, the Turbovnc server instance is permanently affected; even if stop and start the TurboVNC client again.

  4. However after 2 or 3, if I launch another server instance when the physical user is no longer logged, that new server is functional again as in 1.

I can't figure out whether this is a bug or a TurboVNC feature I am misusing (spanning options?); I can't find anything that seems relevant after reading the whole webpage documentation and issue list here. I have tried to play with the spanning options of the TurboVNC client but that doesn't seem to change anything.

I have reproduced this issue with a MacOS version of the TurboVNC client (2.2.6) and also using a NoVNC client I have set up on my own, so it seems to be a client-independent problem.

Thanks for any help! Best regards, JS

dcommander commented 3 years ago

Yeah, the problem is that GDM on Wayland-equipped systems switches the X display of the 3D X server whenever you log in, so whereas you could access the GPU using Display :0 while the system was at the login prompt, when someone is logged in, you can only access the GPU using Display :1. Even before that was the case, there were other limitations that prevented VirtualGL from working properly with local logins (display managers would often reset the 3D X server when a user logged out, thus disconnecting any connections made by VGL and effectively aborting any 3D applications running with VirtualGL.) To make a long story short, VirtualGL simply isn't supportable in conjunction with local logins to the 3D X server. It causes problems such as these, and it also represents a security risk.

Solutions/workarounds:

  1. Set up a separate local X server to use solely for local logins, and set up a dedicated headless 3D X server to use with VirtualGL. This would require multiple GPUs and some display manager customizations.
  2. Use the EGL back end in VirtualGL 3.0, which allows you to access the GPU without going through a 3D X server. This is currently still experimental and hasn't entered beta yet, but you can test it in the 3.0 pre-release build. It probably requires an nVidia GPU at the moment.
  3. Don't use -vgl with your TurboVNC session. GNOME will still be usable without it, and you can still use VirtualGL on demand in the TurboVNC session by invoking vglrun. You will just have to be mindful of the change in the 3D X server display when someone is logged in and pass -d :1 to vglrun accordingly.
jsfrancal commented 3 years ago

Thanks a lot for the very helpful reply. I have updated my deployment scripts based on suggestion 3 and that works.

Just for feedback I first did attempt suggestion 2 by installing version 2.6.80, setting it up with vglserver_config, and setting VGL_DISPLAY=/dev/dri/card0 before launching the server or using option -d /dev/dri/card0 with the vglrun command line in the remote server, both suggested in the Change Log, but that gives a black screen or black window. All our GPUs are NVidia. Thanks a lot though.

dcommander commented 3 years ago

I’ll look into the issue with the EGL back end. It may be that the window manager requires the GLX texture-to-pixmap extension, which is not yet implemented in the EGL back end. I’m still seeking funding to finish that feature and document it.

dcommander commented 2 years ago

Sorry that I failed to post an update in a timely manner. I have been unable to reproduce any issues with popular window managers, including GNOME, and the EGL back end. All of the window managers listed in the TurboVNC 3.0 Window Manager Compatibility Report were tested with both the GLX and EGL back ends.