GNOME Bugzilla – Bug 334088
vino as a remote controller
Last modified: 2020-11-12 12:24:23 UTC
That is, using vino and a vnc client to control the desktop, not sending any image to vnc client to save bandwidth. A scenario may be one projector to serve as the display for all. Everyone have a vncviewer to control the desktop together. Vino should have an option in preference dialog or in confirm dialog to allow user to specify whether sending images.
This sounds too specific to me. Adding such option either in prefs window or in connect dialog could make some confusion, IMHO. Mark, what do you think about that?
This bug hasn't seen any recent activity. I was wondering whether there was any progress on this. Currently, I'm having a similar issue with vino as a server and x2vnc as a remote control client. Referencing Comment #1, a less confusing (and far more popular option for other purposes) might be to be able to select the display depth and resolution that is transmitted. Anything to reduce bandwidth and display processing would be greatly useful, for more than just remote control. Ideally vino should have an option to transmit the same low-resolution static image with a message (so that clients that expect an image see an informative message and aren't confused when they connect with this option enabled). At the very least, most vnc servers have similar options for display resolution and depth. Vino is severely lacking in common vnc options. x0vncserver is a good alternative, but is far more complex and can get buggy when trying to do this sort of thing remotely. Vino therefore makes more sense but is too weak when it comes to common options.
Vino is not under active development anymore and unmaintained. Please use gnome-remote-desktop instead. Closing this report as WONTFIX to reflect reality.