On 1/11/24 2:35 PM, Felix Natter wrote:
thanks, using MATE and lightdm it works fine (tvnc 3.1.1):
G3 + lightdm + G3 in VNC = bug
mate + lightdm + G3 in VNC = OK
G3 + lightdm + mate in VNC = OK
G3 + gdm + mate in VNC = bug
The issue is also OK if using :2 without "-listen local".
In your initial post in this thread, you said you were using TurboVNC
3.1, which did not enable '-listen local' by default. You did not
specify that you were enabling '-listen local', so I was not testing
with that option enabled. I was able to reproduce the issue once with
'-listen local' enabled, by starting the TurboVNC session from a shell
in the local GNOME session. However, I couldn't reproduce the issue
after that, so it appears to be intermittent at least. If you can
provide more specifics about how you are starting the TurboVNC session
(and in what order relative to logging in locally), that may help me
reproduce the issue more consistently. We already know that GDM does a
very poor job of playing nice with other X servers, given that it stomps
on TurboVNC's display if TurboVNC is listening on /tmp/.X11-unix/X1 but
not listening on the equivalent abstract Unix domain socket. That is,
in fact, the main reason why I started enabling '-listen local' by
default in TurboVNC. Maybe GDM also does something to interfere with
X11 abstract Unix domain sockets when you log out. If I could
consistently reproduce the issue, I could probably diagnose it.
<rant>
I'll be frank. GDM and GNOME are acting like playground bullies here,
and my strong inclination is to kick them off the playground rather than
try to placate them. I'm sick of open source developers acting as if
local Linux sessions are the only thing that matters. It probably has a
lot to do with the pervasive myth that Linux desktops matter, when the
reality is that Linux has a 3-4% market share among desktop operating
systems. An honest reckoning with that would lead one to conclude that
Linux should lean into on-demand remote virtual desktop solutions rather
than making those solutions more difficult. TurboVNC and VirtualGL are
in their 20th year, they are deployed in most supercomputer centers, and
numerous large organizations (both public and private) use them for
on-demand remote access to large-scale computing and graphics
resources. Is it too much to ask that we not be treated like red-headed
stepchildren? I'm sick of spending my life hacking around other
people's lack of forethought, and I'm even sicker of being paid a
pittance for it.
</rant>
I also attach a server + client log in the error case
(G3 + gdm + G4 in VNC) in case you have an idea.
Regarding virtualgl: On a box I ran "vglserver_config" before having
lightdm installed.
Can I just "unconfigure" and then reconfigure it so that it configures
lightdm also?
You don't even need to unconfigure it. You can just configure it
again. vglserver_config is idempotent, meaning that it won't configure
anything that is already configured.
--
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/ce4a9be4-6583-fd83-8455-9c304abb2f08%40virtualgl.org.
