If enabled, set the thread name at creation (on GNU systems with
  pthread_set_np)
Fix up all the callers with a thread name
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>

Rework DisplayStateListener callbacks to not use the DisplayState
any more.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Add missing 'static' qualifiers.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

The vnc code uses *three* DisplaySurfaces:

First is the surface of the actual QemuConsole, usually the guest
screen, but could also be a text console (monitor/serial reachable via
Ctrl-Alt-<nr> keys).  This is left as-is.

Second is the current server's view of the screen content.  The vnc code
uses this to figure which parts of the guest screen did _really_ change
to reduce the amount of updates sent to the vnc clients.  It is also
used as data source when sending out the updates to the clients.  This
surface gets replaced by a pixman image.  The format changes too,
instead of using the guest screen format we'll use fixed 32bit rgb
framebuffer and convert the pixels on the fly when comparing and
updating the server framebuffer.

Third surface carries the format expected by the vnc client.  That isn't
used to store image data.  This surface is switched to PixelFormat and a
boolean for bigendian byte order.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Fix some minor typos/grammar errors in comments.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

QEMU now has a fundamental requirement for pthreads, so there
is no compelling reason to retain support for the non-threaded
VNC server. Remove the --{enable,disable}-vnc-thread configure
arguments, and all CONFIG_VNC_THREAD conditionals
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The threaded VNC servers messed up with QEMU fd handlers without
any kind of locking, and that can cause some nasty race conditions.

Using qemu_mutex_lock_iothread() won't work because vnc_dpy_cpy(),
which will wait for the current job queue to finish, can be called with
the iothread lock held.

Instead, we now store the data in a temporary buffer, and use a bottom
half to notify the main thread that new data is available.

vnc_[un]lock_ouput() is still needed to access VncState members like
abort, csock or jobs_buffer.
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Split from Jan's original qemu-thread-posix.c patch.  No semantic change,
just introduce the new API that POSIX and Win32 implementations will
conform to.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

qemu_malloc/qemu_free no longer exist after this commit.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

We have qemu_cpu_self and qemu_thread_self. The latter is retrieving the
current thread, the former is checking for equality (using CPUState). We
also have qemu_thread_equal which is only used like qemu_cpu_self.

This refactors the interfaces, creating qemu_cpu_is_self and
qemu_thread_is_self as well ass qemu_thread_get_self.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

VncJobQueue's buffer is intended to be used for
as the output buffer for all operations in this queue,
but unfortunatly.

vnc_async_encoding_start() is in charge of setting this
buffer as the current output buffer, but
vnc_async_encoding_end() was not writting the changes back
to VncJobQueue, resulting in a big and ugly memleak.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Add ZRLE [1] and ZYWRLE [2] encodings. The code is inspire^W stolen
from libvncserver (again), but have been rewriten to match QEMU coding
style.

[1] http://www.realvnc.com/docs/rfbproto.pdf
[2] http://micro-vnc.jp/research/remote_desktop_ng/ZYWRLE/publications/Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

If an adaptive encoding has choosen to send a lossy update
based on the result of vnc_update_freq(), then it should advertise
it with vnc_sent_lossy_rect(). This will allow to automatically refresh
this rect once it's static again.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

agraf reported that qemu_mutex_destroy(vs->output_mutex) while failing
in vnc_disconnect_finish().

It's because vnc_worker_thread_loop() tries to unlock the mutex while
not locked. The unlocking call doesn't fail (pthread bug ?), but
the destroy call does.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Implement a threaded VNC server using the producer-consumer model.
The main thread will push encoding jobs (a list a rectangles to update)
in a queue, and the VNC worker thread will consume that queue and send
framebuffer updates to the output buffer.

The threaded VNC server can be enabled with ./configure --enable-vnc-thread.

If you don't want it, just use ./configure --disable-vnc-thread and a syncrhonous
queue of job will be used (which as exactly the same behavior as the old queue).
If you disable the VNC thread, all thread related code will not be built and there will
be no overhead.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>