Highlite:
* use qualityLevel/zlib_buffer. No new variable is needed.
* Change coding style to recursive fashion.
* Change meaning of qualityLevel== 9 for easy calc zywrle_level:
old:zywrle_level== 1
new:disable ZYWRLE(same as ZRLE)
so, we should not use this value for compatible reason.
* Color mode handling isn't complete.
I provided and checked 16 bit colors(RGB555,RGB565) and
some color mode of 32 bit colors for little endian mode.
we must make and check 24 bit colors and big endian mode.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
For some reason, I swapped buttons 2 and 3 on Dec 7, 2005, in commit
"translate keys based on unicode (much more reliable than sym)".
I do not remember why, nor what I smoked, but this was wrong.
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