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.
rohit_99129
dscho
runge