Felix,
Can you please provide more specific information about how you are
starting the TurboVNC session (and in what order relative to logging in
locally?) I would still like to reproduce this issue and attempt to fix it.
DRC
On 1/12/24 12:18 PM, DRC wrote:
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/3ac0b52d-e96d-473c-5b57-3e8c72709d2f%40virtualgl.org.
