Add multiple monitor spanning feature to java viewer
Adds support for spanning multiple monitors in "Extended" mode
to the Java viewer. Allows for spanning when maximizing in
addition to just full-screen mode. Seems a bit unpredictable on
MS Windows 7 (ie: depends on window placement, which screen is
set as primary, etc.), but this appears to be the behavior of
the OS itself.
desktopSize preference was being applied even if the checkbox was
unselected in the dialog is a value had previously been stored in
the preferences file.
Added patches for the following upstream CVEs: 2013-7439,
2015-0255, 2015-1802, 2015-1803, 2015-1804. Also updated the
versions of gnutls, libtasn1, and libjpeg-turbo used to build
static libraries to their latest respective upstream versions.
Added patches for the following upstream CVEs: 2013-7439,
2015-0255, 2015-1802, 2015-1803, 2015-1804. Also updated the
versions of gnutls, libtasn1, and libjpeg-turbo used to build
static libraries to their latest respective upstream versions.
Desktop environments like to change to the monitor's preferred
mode, especially at login. Lacking one, they pick the highest
resolution they can find. This tends to override what the user
has picked, so try to work around the desktop environments by
setting the preferred mode to what the user has chosen.
Credit goes to Michal Srb who figured out the problem.
The bug fix in b64dbf2 didn't account for the proper request
region in the case of continuous updates. Make sure we use the
proper variable for which region we've sent updates for.
A request may be for only part of the frame buffer, meaning we cannot
discard all changes just because we've send out an update. There might
still be modified areas remaining that haven't been requested yet.
Variables were reused a bit too heavily and it was possible to get
the logic at a point where the server would try to render a cursor
where it wasn't needed, and the empty update rect would cause a
crash. Clear things up by introducing some more explicit variables.
Change fillRect() to take a buffer instead of a pixel
There has been some confusion if fillRect() should accept a buffer
or a pixel. This can cause misrendering if your data is not in the
native endian order. A buffer makes more sense here though, and
is what most of the callers are already assuming, so change the
API to follow that.
We cannot handle a reset properly right now and are forced to terminate
instead. Avoid surprising people with a dying Xvnc by changing the default
to -noreset.
This is needed in order to get libtool to treat them as normal
libraries and not "convenience libraries". The latter are linked
with --whole-archive, which pulls a lot of unnecessary stuff into
Xvnc and libvnc.so.