William Sjöblom [Wed, 24 Nov 2021 11:55:44 +0000 (12:55 +0100)]
Be consistent in "full screen" and "full-screen" use
Previously, there were a number of inconsistencies in the use of
"full-screen" and "full screen" in logs, documentation, and user
interfaces. The consensus seems to be that "full screen" is correct when
used as a noun while "full-screen" is correct when used as an
adjective. These inconsistencies have now been adjusted to follow
consensus.
Pierre Ossman [Fri, 5 Nov 2021 11:53:11 +0000 (12:53 +0100)]
Raise CMake requirement to 3.10
It's difficult to support both old and new versions, so raise the
requirement to the oldest that is commonly used, which is CMake 3.10.2
on Ubuntu 18.04.
Pierre Ossman [Fri, 5 Nov 2021 12:06:07 +0000 (13:06 +0100)]
Don't specify SOURCE in custom targets
They don't really contribute to anything as the command line is fixed,
and it makes CMake 3.20+ upset since it cannot find that file and
instead thinks we meant maketarball.in (CMP0115).
Pierre Ossman [Thu, 4 Nov 2021 08:01:08 +0000 (09:01 +0100)]
Increase maximum input buffer
macOS' built in VNC server unfortunately sends the entire monitor in a
single rect, so we need to be prepared to buffer a lot of data in case
the monitor has a large resolution.
Pierre Ossman [Thu, 14 Oct 2021 10:42:05 +0000 (12:42 +0200)]
Fix closing reconnect dialog logic
If you close the reconnect dialog then we should assume that you want to
close things, not that you want to reconnect. Unfortunately FLTK returns
the first choice when closing the dialog, so that needs to be the
"Cancel" alternative.
Samuel Mannehed [Wed, 6 Oct 2021 12:06:22 +0000 (14:06 +0200)]
Workaround options window appearing behind viewer
FLTK's fullscreen_x() function will always put the window on a high
level (NSStatusWindowLevel = 25), even if the window doesn't have focus.
This causes the OptionsDialog to end up behind the DesktopWindow when
the fullscreen function is called. Until we can rest assured that most
people building TigerVNC will use a fixed version of FLTK, we will need
this workaround.
Samuel Mannehed [Tue, 5 Oct 2021 14:28:59 +0000 (16:28 +0200)]
Remove modal property from ServerDialog
Modal windows are meant to be child windows such as menus or popups that
are intended to always appear in front of its parent.
Modal FLTK windows without a parent seem to behave strangely on macOS.
Such windows can appear in front of their modal children windows.
When opening OptionsDialog from ServerDialog, it was easy to get to a
broken state by then switching focus back to the ServerDialog. This
would cause the ServerDialog to appear in front, but not be useable as
the options window would still have control of mouse and keyboard.
Additionally, modal windows without parents appear in front of other
normal applications on macOS. This means that the ServerDialog couldn't
be put behind Safari for example.
The fact that ServerDialog was a "modal" window was a bit strange,
seeing as it doesn't have any parent windows. Removing the modal
property from this window causes all the strange-ness to go away.
Samuel Mannehed [Thu, 23 Sep 2021 14:31:59 +0000 (16:31 +0200)]
Only grab keyboard when we have focus
There was an issue with the new grabs that were introduced in commit 2289342de7222e4ff2483eae95bb9898830e6097. On macOS when running
vncviewer in fullscreen on one monitor, we saw that we sometimes got
resize and fullscreen events when switching the focus away from
vncviewer. With the changes in the commit mentioned above this meant
that we immediately grabbed the keyboard again, thus never releasing it.
Pierre Ossman [Thu, 9 Sep 2021 10:24:50 +0000 (12:24 +0200)]
Give all monitor names when mirrored
If a monitor is part of a set of mirrored monitors, then give the name
of all used monitors as we don't know which one the user will most
strongly associate with what they see.
Pierre Ossman [Thu, 9 Sep 2021 09:04:21 +0000 (11:04 +0200)]
Fix corner case in monitor index calculation
Fix a bug in the comparison function that could result in the wrong
index being assigned to a monitor. Change the logic to more directly map
to the description.
Pierre Ossman [Thu, 9 Sep 2021 09:01:47 +0000 (11:01 +0200)]
Handle mirrored monitors on X11
macOS and Windows present mirrored monitors as a single virtual monitor,
but X11 exposes this scenario as two distinct monitors with identical
coordinates. This messes up our logic, and is likely confusing for the
user. So instead we'll ignore any monitors that have identical
coordinates to any already seen monitors.
Pierre Ossman [Thu, 2 Sep 2021 14:28:16 +0000 (16:28 +0200)]
Tolerate carriage return in config files
If the file has been transferred from a Windows system then it might
have \r\n line endings instead of \n. Make sure this doesn't leak in to
the parameter values.
Pierre Ossman [Tue, 20 Jul 2021 14:38:04 +0000 (16:38 +0200)]
Keep ownership of second selection when first is lost
This fixes regression introduced by the extended clipboard extension.
Previously it was possible for the server to hold on to the CLIPBOARD
selection even if another application took ownership of PRIMARY. This is
important to handle the common use case of selecting something in order
to paste over it.
The new request based model doesn't readily support this as we assume
the client has lost its data once we push the new PRIMARY selection to
it. So to handle this we have the maintain a cache of the client's data,
and make sure to fill that cache before we do anything that might cause
the client to lose the data.
Hugo Lundin [Fri, 16 Jul 2021 14:31:16 +0000 (16:31 +0200)]
Refresh MonitorArrangement on configuration change
MonitorArrangement (in the options dialog) never changes when the system
monitor configuration changes. Therefore, the user can get into a state
where the reality doesn't match what is shown (when a monitor is
added/removed, resolution or position changed etc).
All these changes triggers an event in FLTK
(FL_SCREEN_CONFIGURATION_CHANGED). This commit adds an event handler in
MonitorArrangement and refreshes the widget whenever that event occurs.
Because Fl_Handler does not have a void*-argument (and we must be able
to access the widget from our handler callback) a static set of
instances have been added, which all will receive the events.
Hugo Lundin [Tue, 13 Jul 2021 13:55:54 +0000 (15:55 +0200)]
Add monitor description to tooltip
It might be useful to have more information about a monitor when
configuring its settings in the Options menu. Therefore, this commit
adds support for showing additional information about a monitor
(resolution and platform-specific name).
Hugo Lundin [Thu, 15 Jul 2021 11:32:19 +0000 (13:32 +0200)]
Explicitly choose current monitor
There are no guarantees from the WM that calling `fullscreen_screens`
with all monitor indices set to `-1` results in the window's current
monitor being used. Because FullScreenMode uses the word "current"
we want to explicitly ask the WM to use that monitor.
Hugo Lundin [Tue, 13 Jul 2021 11:58:12 +0000 (13:58 +0200)]
Add fullscreen mode for selected monitors
The user might not always want to use all monitors when in fullscreen
mode, but instead only a few. This commit adds support for configuring
selected monitors from command line, in the config file and graphically
in the options menu.
Because it might be hard to guarantee the consistency of monitor
identifiers coming from third-parties (for example FLTK), it has been
decided to use our own numerical identifier. This identifier is based on
the monitor's positions. The mapping between this identifier and the
indices used by FLTK is done by MonitorIndicesParameter.
Hugo Lundin [Thu, 15 Jul 2021 10:52:56 +0000 (12:52 +0200)]
Add fullscreen mode parameter
Before this commit, `FullScreen` and `FullScreenAllMonitors` could be
used to configure whether to use the current monitor in fullscreen,
or all monitors in fullscreen.
This commit deprecates `FullScreenAllMonitors` in favour of
`FullScreenMode` (which can either be `current` or `all`). This allows
for additional modes to be added, without the risk of having invalid
states (for example two activate two different fullscreen modes at the
same time).
A new concept has been added; read-only parameters. They are parameters
that will be read, but never written back. This allows for migration
paths to be constructed, where a parameter can be taken to consideration
but then for example be discarded, logged or changed into something else.
This has been used for `FullScreenAllMonitors` to provide a migration
path. On startup of vncviewer, if `FullScreenAllMonitors` is enabled,
`FullScreenMode=all` will be automatically enabled instead. The next
time the configuration file is written to disk, `FullScreenAllMonitors`
will then be removed.
Hugo Lundin [Wed, 14 Jul 2021 12:55:56 +0000 (14:55 +0200)]
Calculate overlay position from window size
Previously, it was assumed that all monitors (and especially the primary
monitor, index 0) was inside the window when we calculate the position
of the overlay.
That might not always be the case, for example when using fullscreen
mode over a narrower set of monitors. This commit does so the overlay is
positioned correctly based on the actual window size, instead of what we
expect it to be.
Hugo Lundin [Fri, 16 Jul 2021 11:26:08 +0000 (13:26 +0200)]
Release displays not enclosed by the window
cocoa_capture_displays it captures all displays enclosed by the
window_rect. If a set of displays were captured, but the configuration of
what monitors to use changed, a second call would only add to the set
of captured displays. Therefore, if the user enabled
FullScreenAllMonitors (all displays captured) and then disabled it (only
one display captured) they would get into a state were monitors not used
for the VNC session still were captured (which on macOS for example,
results in displays being unusable for other things).
This has now been fixed, resulting in monitors outside the window_rect
not being unnecessarily captured.
Hugo Lundin [Tue, 13 Jul 2021 11:07:41 +0000 (13:07 +0200)]
Capture all displays inside the viewport (macOS)
It was only possible to capture either the current, or all displays
previously. This could become an issue if you want to show a vnc session
over only a selected set of displays, because then we only want to
capture those displays.
The solution in the commit was chosen because it handles all cases - by
looking at what monitors are enclosed by the viewport the implementation
is independent on any configuration, but instead captures the monitors
actually being used.
Alex Richardson [Wed, 14 Jul 2021 13:13:54 +0000 (14:13 +0100)]
Rename Input.h to vncInput.h to fix building on case-insensitive FS
I am cross-compiling from macOS for a FreeBSD-derived system so my host
file system is case insensitive but the target isn't. Without this change
I get the following warnings which show that the vnc "Input.h" is being
included from mi/mi.h instead of the xserver "input.h":
```
In file included from /Users/alex/cheri/xvnc-server/hw/vnc/Input.c:33:
/Users/alex/cheri/xvnc-server/mi/mi.h:55:10: warning: non-portable path to file '"Input.h"'; specified path differs in case from file name on disk [-Wnonportable-include-path]
#include "input.h"
^~~~~~~~~
"Input.h"
```
Alex Richardson [Wed, 14 Jul 2021 13:01:15 +0000 (14:01 +0100)]
Fix build on systems without HOST_NAME_MAX
Some operating systems such as FreeBSD don't define a HOST_NAME_MAX
macro. The portable approach to determine the real host name limit is
calling sysconf(_SC_HOST_NAME_MAX) so do that instead.
Pierre Ossman [Tue, 13 Jul 2021 10:42:56 +0000 (12:42 +0200)]
Remove vfb references from symbol names
Xvnc was originally based on Xvfb, but it's just confusing to keep the
names. So change all prefix to "vnc" instead to clearly mark things as
part of TigerVNC.
Pierre Ossman [Sun, 11 Jul 2021 18:59:48 +0000 (20:59 +0200)]
Handle X.org patch level features
With the 1.20.x releases there has been features and API changes even on
patch level versions, so we need to update our macros to handle these as
well.