While adjusting the coding style, three stupid mistakes happened. The
quality is _not_ just 1, 2, 3, but really 1, 3, 2. And the macros
ZYWRLE_PACK_COEFF() and ZYWRLE_UNPACK_COEFF() expand to more than one
statement, which means that we need curly brackets around them when they
are in an if clause.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We used to assume that a char[256] is properly aligned to be cast to
an rfbServerInitMsg, but that was not the case. So use a union instead.
Noticed by Flavio Leitner.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There seems to be a locking problem in libvncserver, with respect to how
condition variables are used.
On certain machines in our lab, when using a vncviewer to view a display
that has a very high rate of updates, we will occasionally see the VNC
server process crash. In one stack trace that was obtained, an assertion
had tripped in glibc's pthread_cond_wait, which was called from
clientOutput.
Inspection of clientOutput suggests that WAIT is being called incorrectly.
The mutex that protects a condition variable should always be locked when
calling wait, and on return from the wait will still be locked. The
attached patch fixes the locking around this condition variable, and one
other that I found by grepping the source for similar occurrences.
Signed-off-by: Charles Coffing <ccoffing@novell.com>
rfbEncodingSupportedEncodings - What encodings are supported?
rfbEncodingSupportedMessages - What message types are supported?
rfbEncodingServerIdentity - What is the servers version string?
ie: "x11vnc: 0.8.1 lastmod: 2006-04-25 (LibVNCServer 0.9pre)"
dscho
runge
steven_carr
rohit_99129