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.
do not make requestedRegion empty without reason.
the cursor handling for clients which don't handle CursorShape updates was
completely broken. It originally was very complicated for performance
reasons, however, in most cases it made performance even worse, because at
idle times there was way too much checking going on, and furthermore,
sometimes unnecessary updates were inevitable.
The code now is much more elegant: the ClientRec structure knows exactly
where it last painted the cursor, and the ScreenInfo structure knows where
the cursor shall be.
As a consequence there is no more rfbDrawCursor()/rfbUndrawCursor(), no more
dontSendFramebufferUpdate, and no more isCursorDrawn. It is now possible to
have clients which understand CursorShape updates and clients which don't at
the same time.
rfbSetCursor no longer has the option freeOld; this is obsolete, as the cursor
structure knows what to free and what not.
Christian Beier
Johannes Schindelin
Vic Lee
dscho
runge
steven_carr
markmc