Since autotools officially is no longer supported (see various github
issues), drop the related infrastructure to stop tempting people to use
it for building.
Signed-off-by: Bert van Hall <bert.vanhall@gmx.de>
Since we connected to the client through the repeater, chances are
that we want this server shut down once the client disconnected.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
UltraVNC offers an add-on to connect clients and servers via IDs with
a so-called repeater (e.g. to bridge firewalled clients and servers):
http://www.uvnc.com/products/uvnc-repeater.html
This example demonstrates how to use that feature with a
LibVNCServer-based server.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
without a touch screen. Because fake touch screen always report
zero when query device information, coordinates transformation is not
needed.
Signed-off-by: Christian Beier <dontmind@freeshell.org>
If people seriously consider building with Visual Studio, there is
always CMake.
Pointed out by Christian Beier.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Adds automagically generating libvncserver/libvncclient API
documentation using doxygen. This gives a nice overview on both APIs,
include dependencies and function call/caller dependencies.
TODO: Modify all the explaining comments in the .c files for use with
doxygen as well.
This patch only changes comments, no functional changes at all!
Signed-off-by: Christian Beier <dontmind@freeshell.org>
The flag handling (both compiler options and include paths) are a mess at
the moment. There is no point in forcing "-O2 -g" when these are already
the defaults, and if someone changes the defaults, chances are good they
don't want you clobbering their choices.
The -Wall flag should be handled in configure and thrown into CFLAGS once
rather than every Makefile.am. Plus, this way we can control which
compilers the flag actually gets used with.
Finally, the INCLUDES variable is for -I paths, not AM_CFLAGS. Nor should
it contain -I. as this is already in the default includes setup.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We cannot write access the frame buffer, and we do not have a sensible
cursor anyway, so better disable the cursor (which would have to be drawn
for clients that do not support CursorShapeUpdates).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
If the client asked for an encoding, and no enabled extension handled it,
LibVNCServer would walk through all extensions, and if they promised to handle
the encoding, execute the extension's newClient() if it was not NULL.
However, if newClient is not NULL, it will be called when a client connects,
and if it returns TRUE, the extension will be enabled. Since all the state of
the extension should be in the client data, there is no good reason why
newClient should return FALSE the first time (thus not enabling the extension),
but TRUE when called just before calling enablePseudoEncoding().
So in effect, the extension got enabled all the time, even if that was not
necessary.
The resolution is to pass a void** to enablePseudoEncoding. This has the
further advantage that enablePseudoEncoding can remalloc() or free() the
data without problems. Though keep in mind that if enablePseudoEncoding()
is called on a not-yet-enabled extension, the passed data points to NULL.
Christian Beier
Bert van Hall
Stefan Weil
zbierak
Brian Bidulock
Johannes Schindelin
William Roberts
ckanru
Vic Lee
dscho
runge
steven_carr