Can you explain more about your particular use case? The typical use
case for TurboVNC is that you have a "primary" connection-- that is, a
connection from the owner of the TurboVNC session-- and you have
secondary connections from "collaborators", but it sounds like your use
case may be different than that.
It is certainly possible to force only one connection at a time by
disabling session sharing. There are three server-side options that
control sharing: -dontdisconnect, -alwaysshared, and -nevershared.
They work as follows:
{none of the options}:
NOTE: This is not actually possible in TurboVNC without editing the
vncserver script, because that script is hard-coded to pass
-dontdisconnect to Xvnc. I've personally never found the behavior of
the server without -dontdisconnect useful, but if someone else does,
then we can certainly make that behavior available without editing the
vncserver script.
NOTE: This is the default behavior in TigerVNC and RealVNC.
If a new viewer authenticates and connects successfully without
"shared session" enabled in the viewer settings, then all existing
viewers are disconnected. (Yeah, that's why I don't find this option
useful. It's rather disconcerting if you're working in a VNC session
and it suddenly goes away because someone else connected.)
-dontdisconnect:
NOTE: This is the default behavior in TurboVNC.
If a new viewer authenticates and connects successfully without
"shared session" enabled in the viewer settings, then the new viewer is
immediately disconnected.
-alwaysshared:
The "shared session" setting from viewers is ignored, and all of them
are treated as if they have "shared session" enabled. Thus, no viewer
is ever disconnected when a new viewer connects.
-nevershared:
NOTE: This is not actually possible in TurboVNC without editing the
vncserver script, because that script is hard-coded to pass
-dontdisconnect to Xvnc.
The "shared session" setting from viewers is ignored, and all of them
are treated as if they have "shared session" disabled. Thus, if a new
viewer authenticates and connects successfully, then all existing
viewers are disconnected.
-nevershared -dontdisconnect:
The "shared session" setting from viewers is ignored, and all of them
are treated as if they have "shared session" disabled. Thus, if a new
viewer authenticates and connects successfully, then it is immediately
disconnected.
As far as remote desktop resizing, it is possible to achieve what you
want manually, but it would require that the client with the smaller
screen voluntarily switch off automatic desktop resizing before the
larger-screen client connects. The basic problem with trying to enforce
any automatic behavior, other than the current behavior, is that the
server doesn't know what size the client screens are, nor does it know
which viewer should be given precedence over the others. Thus, it
currently treats all viewers as equal. It would be straightforward to
treat one viewer as the "primary" viewer and ignore remote desktop
resize requests from the other viewers, but there would be no way of
giving a viewer precedence based on its client screen size, because the
server doesn't have that information. The best we could do is to either
give precedence to the first connection or to the most recent
connection. At the moment, the only way that the server has of
differentiating between primary and secondary connections is the
view-only setting. If a client authenticates using view-only
credentials (either a view-only VNC password or OTP token, or PAM
credentials that were added to the TurboVNC session's view-only ACL),
then the server could easily ignore remote desktop resize requests from
such clients, but of course those clients would not be allowed to send
keyboard or mouse events. Perhaps there needs to be a third set of
credentials called "collaborate-only"? That is certainly
straightforward to implement, but I would need more information about
what exactly you are trying to achieve.
What happens now:
When the larger-screen client connects with automatic desktop resizing
enabled, it sends a desktop resize request to the server to attempt to
make the server's desktop fit in the viewer's window without using
scrollbars. The server honors the request and sends out a desktop
resize message to all connected viewers. The smaller-screen client
attempts to resize its window to accommodate the new larger desktop
size. It figures out that it can't do that without using scrollbars, so
it resizes its window to the largest size it can accommodate without
scrollbars, and it sends back a desktop resize request to the server.
The server honors this new request, which shrinks the desktop back to
its old size, and the new (old) size is sent back to the larger-screen
viewer. In order to prevent an infinite loop, the viewers always accept
a new remote desktop size from the server if it is smaller than their
maximum window size. They only try to "fight the system" if the remote
desktop size is bigger than their maximum window size. Basically, the
current viewer behavior is designed such that no viewer with automatic
desktop resizing enabled will ever have scrollbars, but that requires
that all viewers shrink their windows to accommodate the client with the
smallest screen.
>From the server's point of view, it doesn't know whether a remote
desktop resize request was due to automatic desktop resizing or whether
the viewer was trying to manually set the remote desktop size. From the
viewer's point of view, however, it does know whether a remote desktop
resize was triggered by another viewer, so conceivably, the behavior
could be changed such that a viewer accepts remote desktop resizes from
other viewers without question. However, this would only be a
meta-stable state. As soon as a viewer window size changes, it would
trigger a new desktop resize request to the server, and that would cause
the same sequence of events described above, resulting in the
larger-screen clients having to accept a smaller-than-optimal desktop
size. The only way to avoid this is to assign some kind of precedence
order to the viewers and enforce it on the server, but per above, that
precedence order unfortunately can't be based on the client screen size.
On 12/8/16 4:31 AM, [email protected] wrote:
> Scenario:
> - One server running turbovnc
> - One client connects to the server, with a fairly low-res screen. So
> far so good.
> - Another client with a better screen connects to the same server, and vnc
> session. The
> connection works, but its not possible to enlarge the vnc window to fit
> the larger physical screen on the new client. The window is
> automatically downsized to the size of the smallest connected client.
>
> How can I solve this? Several options would be acceptable:
> - the remotes that have too small screen could be scaled to fit
> automatically
> - they could be kicked out of the vnc session
> - they could simply get resized windows that are larger than the
> physical screen.
>
> Any hints how to solve this would be apreciated!
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
TurboVNC-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/turbovnc-users
