← Back to team overview

epoptes team mailing list archive

[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.

  improve support for tigervnc

Status in Epoptes:

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: