| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This is needed because xtigervncviewer now fails to forward the input
from the other side when launched in this way.
There is the same buggy behavior in xtightvncviewer when connecting
in the 'reverse' style -- which has been removed from this code base
because of that regression.
The system as it is now uses both tiger and tight viewers. It uses
tiger locally and tight when it projects the display remotely. But
only tight has proven reliable in operation. Tight should be available
locally.
Tiger is preferred because it supports use of a socket file and because
it supports many other features and has a superior UI. But these
features are not worth bugs and unreliability.
|
|
|
|
|
|
|
|
This requires relying on xtigervncviewer on the remote side, since only
tiger supports connecting to a unix socket file.
This is for -r only. The regular connection still uses TCP :(
|
|
|
|
|
|
|
|
Works around regression in xvncviewer where reverse connections no
longer work. We now use direct connections for -r. Also, we now
default to direct connections without '-r', since reverse connections
fail to forward mouse+keyboard.
The occupation of the port on both connection sides is not ideal.
Also note that this also shares the local desktop with all other local
users. Limiting the port to the calling user would be a good security
feature!
This may be relevant:
https://serverfault.com/questions/127794/forward-local-port-or-socket-file-to-remote-socket-file/753733#753733
Not sure if either x11vnc or xvncviewer can use socket files.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
