epoptes team mailing list archive
-
epoptes team
-
Mailing list archive
-
Message #01245
[Bug 1655795] Re: improve support for tigervnc
I remembered that gtk-vnc doesn't have listen support, so it's a no go
for now.
Main problem for now is the issue that Alkis opened on tigervnc
upstream, but I don't think we'll get a fix soon enough there.
Opening multiple listening viewers (one per x11vnc connection) could be
a solution, but I'd say we can just go with ssvncviewer which supports
listening for multiple connections in one process.
Regarding "the first monitor/assist work fine, but subsequent attempts require exiting the epoptes gui.", this is mostly on our end and it's due to not waiting for the exit status of the vncviewer process in python, which makes it a zombie, and since xtigervncviewer -listen exits after the first connection is gone, we are left with a zombie process right after the first connection. Fix for that is trivial and will be pushed soon.
--
You received this bug notification because you are a member of Epoptes
Developers, which is subscribed to Epoptes.
https://bugs.launchpad.net/bugs/1655795
Title:
improve support for tigervnc
Status in Epoptes:
New
Bug description:
Debian is dropping support for xvnc4viewer (and xtightvnc) in the
upcoming stretch release, and tigervnc-viewer appears to be *nearly*
compatible with it as a replacement.
The attached patch gets this mostly working, but the xtigervncviewer
processes don't response to the kill signal passed in stopTerminal
(e.g. client -> broadcasts -> stop broadcasts). They also don't
respond to manually killing the pid as root, even with "kill -9"...
the first monitor/assist work fine, but subsequent attempts require
exiting the epoptes gui.
Broadcast windowed mode works, but broadcast fullscreen doesn't appear
to work.
Using ssvnc might be an alternate option, but has a recommends on
"default-jre | java5-runtime" packages, which pulls in quite a few
packages, at least in Debian.
To manage notifications about this bug go to:
https://bugs.launchpad.net/epoptes/+bug/1655795/+subscriptions
References