The compiler might default to something older, so make sure we get
the features we need.

With the new unixcommon library we have things outside of common/,
so make the handling of out-of-tree builds more general.

Change Xserver screen through libXrandr. For complex configurations,
all outputs must have corresponding size modes. As a special case, if
the client requests a single screen with an odd size (for example when
adjusting the size of a non-fullscreen vncviewer), find a smaller
suitable mode, and reduce the framebuffer size as well.

This can be used to test if a layout if possible.

Better to avoid making unnecessary calls, but mainly we want to avoid
logging false errors.

For example, if we have earlier disabled an output because it was too
large for the framebuffer, we should prefer this output when
allocating new outputs.

Move the code that turn off unused outputs to the end.

Also, add support for checking the output connection state.

Apparently this is not necessary when using the internal API, but a
must with libXrandr.

This only matters when using clones, which we do not accept yet. This
patch is for completeness and to avoid future surprises.

Return error if no CRTC.

Screen is a Xvnc thing and not relevant for x0vncserver etc.

RANDR is mandatory since Xorg 1.7, which is the oldest version we
support.

In RandR land, there's a lot of return code confusion. Our wrappers
are using the same return codes as RRCrtcSet, RRScreenSizeSet: 1/TRUE
for success. Fixes:

* vncRandRCreateOutputs did not follow this convention

* A lot of code returned -1 upon failure

* vncRandRDisableOutput returned 0 for already disabled outputs

These two code blocks are not specific to Xvnc/vnc.so, but useful for
x0vncserver as well. RandrGlue.h defines the interface on which
unixcommon depends on.

Compatibility with libXrandr, where the name is in dynamically
allocated XRROutputInfo.

Less confusing, and compatible with libXrandr.

Should use 2 spaces like the rest of the project.

There might be parts of the screen that haven't changed and can
therefore be refreshed. Figure which parts these are and send just
those.

We don't want to waste bandwidth on the lossless refresh if we might
need that bandwidth for a normal update. Try to estimate how much
data we can safely send without interfering.

Resend pixel perfect copies of areas that were previously sent
using a lossy encoder. This is done when there is no normal update
to send, and no congestion.

No need to run all the update machinery when there is no client
connected.

This commit also cleans up the stop handling a bit by moving it to
its own method.

We already have an assignment operator, so no need for this method.

We cannot send updates for a cursor that is outside the requested
region, so make sure we track things properly. This also has the nice
side effect of just re-sending the bits needed when the cursor overlaps
a changed part of the framebuffer.

The handler is for incoming data and we should not be abusing that
class for the writer class. Do proper write prototypes for the
relevant functions.

The previous code would incorrectly also add support for QEMU
key events if LED state was supported.

We don't want to surprise the user with unexpected clipboard changes
when vncviewer is in the background, and it is both wasteful and
possibly insecure to inform the server of every clipboard update
when the user isn't interacting with it.

Apply workaround for FLTK's bad focus handling so that we can let
Viewport handle LED synchronisation without help from DesktopWindow.

That way both incoming and outgoing clipboard are both in the same
place, making things clearer.

The VNC servers aren't great at getting full frames with each update,
so avoid calling it "frames per second" in the statistics as that
can be misleading.

Fixes issue #616

Shift key handling was improved in 30b3f92, but the test documentation
wasn't updated.

Improve AltGr detection even further on Windows so we can detect the
case when Ctrl and AltGr are pressed together.

Try to properly detect the fake CtrlL+AltR sequence Windows sends
when pressing AltGr. This allows us to send more accurate key
events over to the server.

It wasn't properly updated in 3112f50 when it was split off from
x0vncserver.cxx.

In XDesktop::start() we allocate pixel buffer and set it as the backend to the given VNCServer.
In XDesktop::stop() we deallocate the buffer, so we must unset it from the VNCServer as well.
Otherwise the VNCServer could try to access it and crash, for example in deferred update.

Originally calling VNCServertST::setPixelBuffer(PixelBuffer* pb_) with pb_=0 would do nothing.
With this change pb will be set to 0 and deferred update timer will be stopped.

Simple shifting can give noticable rounding errors if there is a large
difference in the number of bits between the formats. Do the proper
thing via a lookup table, the same way things are done for up conversion.

Bit shifting gives an approximate, but not properly accurate value
when upconverting. Do a proper calculation.

Colour map support was removed in b6b4dc6, but x0vncserver didn't
properly check if the X server required it.

Copy paste errors/brain fart:

 - Pixels do not need a factor 8 for any conversion

 - Multiplying bytes by 8 gives bits, so lower case 'b', and bits
   use SI prefixes, not IEC

TriFan and TriStrip were added in 1.12, so we need to have that code
conditional to support older versions of Xorg.