We have a timer after Ctrl is pressed in order to see if an Alt will
come right after. Ctrl + Alt is what windows sends for AltGr.
If a key other than Alt was pressed we knew that we could cancel this
timer, this commit extends that to mouse events too.

Since this detection breaks the true order of events we want to make
a decision as fast as possible.

Switch from using Core events to using X Input events for pointer
devices in order to differentiate between mouse events and touch events.

Because FLTK doesn't understand X Input 2, we intercept these events and
translate them to core events where possible.

If you have the setting "Emulate middle mouse button" turned on, a click
and drag can fail if it is done very quickly. The position of the
initial click will be incorrect in such a case because the timeout will
delay events.

We need to make sure everything happens in the correct order during
startup for the X11 display to open correctly. Primarily it means
we need to parse the arguments and open the display before anything
might make any X11 calls, as we may have a -display argument.

We don't exit here, so it's not a fatal error. It's also a fairly common
scenario, so remove the alert completely.

Makes things more consistent and avoids surprises.

Most window managers won't like this, and it tends to provoke bugs in
FLTK, so let's avoid it. It's probably not what the user wants anyway.

This makes our builds directly compatible with most distributions
without packagers/users having to specify extra flags.

This sets up a more correct session as there are key tasks that
need to be performed by PAM. E.g. systemd will allocate cgroups
and start base services.

In order to easily handle this as a system service the mapping of
displays is now done via a configuration file.

Not every mouse has three buttons e.g. laptops. Some OS might not
have support for middle mouse button emulation.

This commit adds emulation for middle mouse button when pressing both
left and right mouse button simultaneously.

This was not necessary since you could use ESC key or simply just
clicking outside of the context menu to close the menu.

Otherwise such clients cannot use Scroll Lock at all, and that is
probably worse than any effects we might get from getting out of sync.

Since 53f913a we initialize the underlying PixelBuffer with 0x0
dimensions, which means we need to keep more explicit track of what
we are trying to allocate in the setup methods.

If the server doesn't support local cursors and want to render them
itself then we need to make sure the local cursor is invisible.

This also makes sure we always have some cursor allocated, so we can
remove the checks in some places.

Commit 4e61f8dbc5 fixed the GUI but forgot
to change the other places in the code.

There was even some confusion in the RFB protocol regarding this, but
the zlib implementation confirms that accepted values for compression
level is 0-9.

The GUI incorrectly noted the max level to be 6 while it in fact is 9.

Even if this note is true it just adds confusion.

The number of colors used isn't something the end-users should have to
concern themselves with. I intentionally left the information in the
man-pages.

The input stream might no longer be the raw socket, so we need to
query what's currently active. That wrapping stream might have its
own buffering and may have more data even if the socket is drained.

Don't allow subclasses to just override dimensions or buffer details
directly and instead force them to go via methods. This allows us
to do sanity checks on the new values and catch bugs and attacks.

Implements support in both client and server for the extended
clipboard format first seen in UltraVNC. Currently only implements
text handling, but that is still an improvement as it extends the
clipboard from ISO 8859-1 to full Unicode.

In prepartion for better clipboard extensions that can send Unicode
data between the client and server.

Change the internal clipboard API to use a request based model in
order to be prepared for more advanced clipboard transfers.

We convert between UTF-8 and ISO 8859-1 (latin 1) in several places
so create some common routines for this.

We now filter incoming data, which means we can start assuming the
clipboard data is always null terminated. This allows us to clean
up a lot of the internal handling.

This is required by the protocol so we should make sure it is
enforced. We are tolerant of clients that violate this though and
convert incoming clipboard data.

Makes it easier to see what is overloaded and what isn't.

We're usually white listed, but let's be a good citizen and formally
request the keyboard grab ability from the compositor.

Some input sources are still using input methods even though they
claim to be "ASCII" input. This causes our input handling to fail
since we need to query the layout to handle dead keys.

Fortunately there is another API to get the raw, underlying input
source that the input method uses. So let's use that and be sure
that we're always getting something we can use.

The parameter files are used to make sure changes in the UI are
persistent. Storing anything else results in behaviours that the
user has no easy way of changing.

It is already hidden in the UI, so make sure it also is gone as a
command line parameter. This follows the behaviour of the similar
sendPrimary parameter.

We need to make sure it is null terminated on truncation. We also
need to avoid giving a too large size argument or modern gcc will
complain.

It's not common knowledge these days how X geometry is specified, and
even the man page X(7) is missing on many systems now.

FLTK has some options (that we've also documented in the man page)
that should be mentioned in the --help output.

We can use a dummy value here as we set up the buffer and stride
further down in the constructor.

We always sync when we get focus, so this code path is really only
for when the server announces LED state support after we already
have focus.

Make sure we only handle this specific scenario as otherwise we
could end up syncing twice, which just toggles things back and forth
and ends up syncing incorrectly.

Logging revealed that a few empty damage regions are emitted on startup. Those don't need to be rendered to the Surface pixmap.

The Pixmap is filled in as updates from the server arrive. Before the first full update, it would contain undefined contents, which would be rendered onto the ViewPort.
Clearing the Pixmap is only done on startup and when changing the server resolution, so it's not performance critical.

These are not allowed in C++, and have been made optional in C11.
So let's just get rid of them and any issues they may cause.