Adding scaling to tigervncviewer

[Brent W. Baccala]

Hi -

I just joined the list and am thinking about doing some development work on TigerVNC.

Here's the context:

I'm developing a remote desktop extension for Big Blue Button, a video-conferencing system (see bigbluebutton.org).

Basically, I'm embedding a remote desktop into a video conferencing system, primarily targeted at classroom use, so the question arises: "how do we move from sharing a desktop between two or three users to a classroom of 10-20 students?"

My answer is to provide each student with their own desktop, and the teacher gets a Zoom or Hollywood Squares type grid that, instead of showing a grid of videos, shows a grid of desktops.  The teacher can interact with any desktop by clicking on it, and an escape sequence gets them back to the grid.  The teacher also has the ability to screen share any one of the desktops to the entire class.

I've been developing it for a year, and it's pretty much working in alpha release.  My code's home is https://github.com/BrentBaccala/collaborate.

I've learned a lot about the capabilities of various VNC software in the process.  Right now, I'm using Xtigervnc for the desktop servers mainly because it can listen on a UNIX socket for its VNC connections.  The video conferencing system is based on HTML5 and Javascript; it uses the noVNC client.

Creating the grid view is more difficult.  I've thought of coding a custom VNC multiplexer, but I initially implemented this feature by running xvncviewers on an "extra" Xvnc server that the teacher connects to.  I still like doing it this way, because you get all the nice features of X11, so it's easy to use Tk, for example, to put labels on the windows, and the FVWM window manager does a nice job of laying everything out.

So, I need to run a bunch of xvncviewers, laid out on a grid, and then throw in another xvncviewer (this one in full screen mode) when the teacher wants to connect to one of the desktops.

Right now, I'm using ssvncviewer to create the grid because it supports both scaling and UNIX domain sockets.  I used to use ssvncviewer for the full screen function, but switched to tigervncviewer because it's X11 Selection handling is better.  This allows cut-and-paste to work when you're connected to a server that has a full screen vnc viewer connected through to another server.

But I really need both functions in one program.  The teacher might be connecting to a student desktop with a different display geometry, and I want scaling, not panning or a lot of blank space around the edges, and cut-and-paste needs to work, too.

So it looks like I need to either add scaling to tigervncviewer, or fix the selection handling on ssvncviewer.  Since ssvnc hasn't been updated since 2011 or 2013, I'm leaning towards adding scaling to tigervncviewer.

I see that's an open issue here: #274.

Also, the whole nested vnc-within-vnc setup (as opposed to a custom vnc multiplexer) really makes the most sense if the code is fairly optimized to handle the case where a X11 vnc viewer is full screen on an Xvnc desktop.  I'm thinking that optimizing the code for this case makes more sense than a custom multiplexer, because you get (hopefully) nearly the same performance along with all the nice X11 feature mentioned above.

Any comments?

By the way, to build TigerVNC 1.11 on Ubuntu 18 (and Big Blue Button is closely tied to Ubuntu 18), I used the Debian package and ignored the build dependency on xorg-server-source (>= 1.20) and used 1.19.6 instead.  It built.  Any ideas what problems I might run into because of that?

Thanks for any feedback you might offer.

    agape

    brent

[Pierre Ossman]

On 12/03/2021 06:32, Brent W. Baccala wrote:
>
> Any comments?
>

Your use case is probably not the main one we were thinking about for
scaling, but I guess it should be covered by an implementation. So feel
free to start hacking. Such an addition would be most welcome. :)

> By the way, to build TigerVNC 1.11 on Ubuntu 18 (and Big Blue Button is
> closely tied to Ubuntu 18), I used the Debian package and ignored the build
> dependency on xorg-server-source (>= 1.20) and used 1.19.6 instead. It
> built. Any ideas what problems I might run into because of that?
>

That is not a requirement from our end so it must be something Debian
has added. We require 1.16 or newer. And we strongly recommend using the
Xorg included in the distribution to avoid issues. E.g. it's a hard
requirement for a functional libvnc.so.

Regards
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköping https://facebook.com/ThinLinc
Phone: +46-13-214600

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Joachim Falk]

Hi Brent,

Am 12.03.21 um 09:41 schrieb Pierre Ossman:

> On 12/03/2021 06:32, Brent W. Baccala wrote:
>>
>> Any comments?
>>
>
> Your use case is probably not the main one we were thinking about for scaling, but I guess it should be covered by an implementation. So feel free to start hacking. Such an addition would be most welcome. :)
>
>> By the way, to build TigerVNC 1.11 on Ubuntu 18 (and Big Blue Button is
>> closely tied to Ubuntu 18), I used the Debian package and ignored the build
>> dependency on xorg-server-source (>= 1.20) and used 1.19.6 instead.  It
>> built.  Any ideas what problems I might run into because of that?
>>
>
> That is not a requirement from our end so it must be something Debian has added. We require 1.16 or newer. And we strongly recommend using the Xorg included in the distribution to avoid issues. E.g. it's a hard requirement for a functional libvnc.so.

Ubuntu does not really maintain a TigerVNC version it recompiles versions
from Debian. However, they do not fix
the xorg-server-source dependency to correspond to the current Ubuntu version. If you want a backport, you can
use https://salsa.debian.org/debian-remote-team/tigervnc where I also maintain a backport for Ubuntu 18.04 LTS.

Best,

Joachim