aboutsummaryrefslogtreecommitdiff
path: root/ui/vnc.h
AgeCommit message (Collapse)AuthorFilesLines
2015-09-15ui: convert VNC server to use QCryptoTLSSessionDaniel P. Berrange1-9/+6
Switch VNC server over to using the QCryptoTLSSession object for the TLS session. This removes the direct use of gnutls from the VNC server code. It also removes most knowledge about TLS certificate handling from the VNC server code. This has the nice effect that all the CONFIG_VNC_TLS conditionals go away and the user gets an actual error message when requesting TLS instead of it being silently ignored. With this change, the existing configuration options for enabling TLS with -vnc are deprecated. Old syntax for anon-DH credentials: -vnc hostname:0,tls New syntax: -object tls-creds-anon,id=tls0,endpoint=server \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, no client certs: -vnc hostname:0,tls,x509=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \ -vnc hostname:0,tls-creds=tls0 Old syntax for x509 credentials, requiring client certs: -vnc hostname:0,tls,x509verify=/path/to/certs New syntax: -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \ -vnc hostname:0,tls-creds=tls0 This aligns VNC with the way TLS credentials are to be configured in the future for chardev, nbd and migration backends. It also has the benefit that the same TLS credentials can be shared across multiple VNC server instances, if desired. If someone uses the deprecated syntax, it will internally result in the creation of a 'tls-creds' object with an ID based on the VNC server ID. This allows backwards compat with the CLI syntax, while still deleting all the original TLS code from the VNC server. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-09-15ui: fix return type for VNC I/O functions to be ssize_tDaniel P. Berrange1-3/+3
Various VNC server I/O functions return 'long' and then also pass this to a method accepting 'int'. All these should be ssize_t to match the signature of read/write APIs and thus avoid potential for integer truncation / wraparound. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2015-07-08ui: convert VNC websockets to use crypto APIsDaniel P. Berrange1-8/+0
Remove the direct use of gnutls for hash processing in the websockets code, in favour of using the crypto APIs. This allows the websockets code to be built unconditionally removing countless conditional checks from the VNC code. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-9-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-04-01CVE-2015-1779: incrementally decode websocket framesDaniel P. Berrange1-0/+2
The logic for decoding websocket frames wants to fully decode the frame header and payload, before allowing the VNC server to see any of the payload data. There is no size limit on websocket payloads, so this allows a malicious network client to consume 2^64 bytes in memory in QEMU. It can trigger this denial of service before the VNC server even performs any authentication. The fix is to decode the header, and then incrementally decode the payload data as it is needed. With this fix the websocket decoder will allow at most 4k of data to be buffered before decoding and processing payload. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> [ kraxel: fix frequent spurious disconnects, suggested by Peter Maydell ] @@ -361,7 +361,7 @@ int vncws_decode_frame_payload(Buffer *input, - *payload_size = input->offset; + *payload_size = *payload_remain; [ kraxel: fix 32bit build ] @@ -306,7 +306,7 @@ struct VncState - uint64_t ws_payload_remain; + size_t ws_payload_remain; Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-03-18ui: remove separate gnutls_session for websockets serverDaniel P. Berrange1-3/+0
The previous change to the auth scheme handling guarantees we can never have nested TLS sessions in the VNC websockets server. Thus we can remove the separate gnutls_session instance. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-03-18ui: fix setup of VNC websockets auth scheme with TLSDaniel P. Berrange1-0/+2
The way the websockets TLS code was integrated into the VNC server made it essentially useless. The only time that the websockets TLS support could be used is if the primary VNC server had its existing TLS support disabled. ie QEMU had to be launched with: # qemu -vnc localhost:1,websockets=5902,x509=/path/to/certs Note the absence of the 'tls' flag. This is already a bug, because the docs indicate that 'x509' is ignored unless 'tls' is given. If the primary VNC server had TLS turned on via the 'tls' flag, then this prevented the websockets TLS support from being used, because it activates the VeNCrypt auth which would have resulted in TLS being run over a TLS session. Of course no websockets VNC client supported VeNCrypt so in practice, since the browser clients cannot setup a nested TLS session over the main HTTPS connection, so it would not even get past auth. This patch causes us to decide our auth scheme separately for the main VNC server vs the websockets VNC server. We take account of the fact that if TLS is enabled, then the websockets client will use https, so setting up VeNCrypt is thus redundant as it would lead to nested TLS sessions. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-03-18ui: report error if user requests VNC option that is unsupportedDaniel P. Berrange1-2/+2
If the VNC server is built without tls, sasl or websocket support and the user requests one of these features, they are just silently ignored. This is bad because it means the VNC server ends up running in a configuration that is less secure than the user asked for. It also leads to an tangled mass of preprocessor conditionals when configuring the VNC server. This ensures that the tls, sasl & websocket options are always processed and an error is reported back to the user if any of them were disabled at build time. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-03-12vnc: drop display+ws_display from VncDisplayGerd Hoffmann1-3/+3
Nobody cares about those strings, they are only used to check whenever the vnc server / websocket support is enabled or not. Add bools for this and drop the strings. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com>
2015-01-22vnc: track & limit connectionsGerd Hoffmann1-0/+3
Also track the number of connections in "connecting" and "shared" state (in addition to the "exclusive" state). Apply a configurable limit to these connections. The logic to apply the limit to connections in "shared" state is pretty simple: When the limit is reached no new connections are allowed. The logic to apply the limit to connections in "connecting" state (this is the state you are in *before* successful authentication) is slightly different: A new connect kicks out the oldest client which is still in "connecting" state. This avoids a easy DoS by unauthenticated users by simply opening connections until the limit is reached. Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-01-22vnc: remove vnc_display globalGerd Hoffmann1-0/+2
Replace with a vnc_displays list, so we can have multiple vnc server instances. Add vnc_server_find function to lookup a display by id. With no id supplied return the first vnc server, for backward compatibility reasons. It is not possible (yet) to actually create multiple vnc server instances. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com>
2014-07-25vnc update fixGerd Hoffmann1-0/+1
We need to remember has_updates for each vnc client. Otherwise it might happen that vnc_update_client(has_dirty=1) takes the first exit due to output buffers not being flushed yet and subsequent calls with has_dirty=0 take the second exit, wrongly assuming there is nothing to do because the work defered in the first call is ignored. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Peter Lieven <pl@kamp.de>
2014-07-01ui/vnc: fix potential memory corruption issuesPeter Lieven1-6/+8
this patch makes the VNC server work correctly if the server surface and the guest surface have different sizes. Basically the server surface is adjusted to not exceed VNC_MAX_WIDTH x VNC_MAX_HEIGHT and additionally the width is rounded up to multiple of VNC_DIRTY_PIXELS_PER_BIT. If we have a resolution whose width is not dividable by VNC_DIRTY_PIXELS_PER_BIT we now get a small black bar on the right of the screen. If the surface is too big to fit the limits only the upper left area is shown. On top of that this fixes 2 memory corruption issues: The first was actually discovered during playing around with a Windows 7 vServer. During resolution change in Windows 7 it happens sometimes that Windows changes to an intermediate resolution where server_stride % cmp_bytes != 0 (in vnc_refresh_server_surface). This happens only if width % VNC_DIRTY_PIXELS_PER_BIT != 0. The second is a theoretical issue, but is maybe exploitable by the guest. If for some reason the guest surface size is bigger than VNC_MAX_WIDTH x VNC_MAX_HEIGHT we end up in severe corruption since this limit is nowhere enforced. Signed-off-by: Peter Lieven <pl@kamp.de> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-06-23qapi event: convert VNC eventsWenchao Xia1-2/+2
Since VNC_CONNECTED, VNC_DISCONNECTED, VNC_INITIALIZED share some common functions, convert them in one patch. Signed-off-by: Wenchao Xia <wenchaoqemu@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2014-03-10ui/vnc: optimize dirty bitmap trackingPeter Lieven1-0/+4
vnc_update_client currently scans the dirty bitmap of each client bitwise which is a very costly operation if only few bits are dirty. vnc_refresh_server_surface does almost the same. this patch optimizes both by utilizing the heavily optimized function find_next_bit to find the offset of the next dirty bit in the dirty bitmaps. The following artifical test (just the bitmap operation part) running vnc_update_client 65536 times on a 2560x2048 surface illustrates the performance difference: All bits clean - vnc_update_client_new: 0.07 secs vnc_update_client_old: 10.98 secs All bits dirty - vnc_update_client_new: 11.26 secs vnc_update_client_old: 20.19 secs Few bits dirty - vnc_update_client_new: 0.08 secs vnc_update_client_old: 10.98 secs The case for all bits dirty is still rather slow, this is due to the implementation of find_and_clear_dirty_height. This will be addresses in a separate patch. Signed-off-by: Peter Lieven <pl@kamp.de> Reviewed-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-03-10ui/vnc: introduce VNC_DIRTY_PIXELS_PER_BIT macroPeter Lieven1-1/+5
Signed-off-by: Peter Lieven <pl@kamp.de> Reviewed-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2014-03-05input: mouse: switch vnc ui to new coreGerd Hoffmann1-0/+1
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-05-03TLS support for VNC WebsocketsTim Hardeck1-1/+4
Added TLS support to the VNC QEMU Websockets implementation. VNC-TLS needs to be enabled for this feature to be used. The required certificates are specified as in case of VNC-TLS with the VNC parameter "x509=<path>". If the server certificate isn't signed by a rooth authority it needs to be manually imported in the browser because at least in case of Firefox and Chrome there is no user dialog, the connection just gets canceled. As a side note VEncrypt over Websocket doesn't work atm because TLS can't be stacked in the current implementation. (It also didn't work before) Nevertheless to my knowledge there is no HTML 5 VNC client which supports it and the Websocket connection can be encrypted with regular TLS now so it should be fine for most use cases. Signed-off-by: Tim Hardeck <thardeck@suse.de> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Message-id: 1366727581-5772-1-git-send-email-thardeck@suse.de Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-04-29vnc: Support for LED state extensionLei Li1-0/+3
Signed-off-by: Lei Li <lilei@linux.vnet.ibm.com> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Message-id: 1366867752-11578-3-git-send-email-lilei@linux.vnet.ibm.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-04-16console: gui timer fixesGerd Hoffmann1-2/+0
Make gui update rate adaption code in gui_update() actually work. Sprinkle in a tracepoint so you can see the code at work. Remove the update rate adaption code in vnc and make vnc simply use the generic bits instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-03-18vnc: stop using DisplayStateGerd Hoffmann1-2/+1
Rework DisplayStateListener callbacks to not use the DisplayState any more. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-03-18console: kill DisplayState->opaqueGerd Hoffmann1-0/+1
It's broken by design. There can be multiple DisplayChangeListener instances, so they simply can't store state in the (single) DisplayState struct. Try 'qemu -display gtk -vnc :0', watch it crash & burn. With DisplayChangeListenerOps having a more sane interface now we can simply use the DisplayChangeListener pointer to get access to our private data instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2013-01-21vnc: fix possible uninitialized removalsTim Hardeck1-0/+1
Some VncState values are not initialized before the Websocket handshake. If it fails QEMU segfaults during the cleanup. To prevent this behavior intialization checks are added. Signed-off-by: Tim Hardeck <thardeck@suse.de> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-01-21vnc: added initial websocket protocol supportTim Hardeck1-0/+19
This patch adds basic Websocket Protocol version 13 - RFC 6455 - support to QEMU VNC. Binary encoding support on the client side is mandatory. Because of the GnuTLS requirement the Websockets implementation is optional (--enable-vnc-ws). To activate Websocket support the VNC option "websocket"is used, for example "-vnc :0,websocket". The listen port for Websocket connections is (5700 + display) so if QEMU VNC is started with :0 the Websocket port would be 5700. As an alternative the Websocket port could be manually specified by using ",websocket=<port>" instead. Parts of the implementation base on Anthony Liguori's QEMU Websocket patch from 2010 and on Joel Martin's LibVNC Websocket implementation. Signed-off-by: Tim Hardeck <thardeck@suse.de> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-01-21vnc: added buffer_advance functionTim Hardeck1-0/+1
Following Anthony Liguori's Websocket implementation I have added the buffer_advance function to VNC and replaced all related buffer memmove operations with it. Signed-off-by: Tim Hardeck <thardeck@suse.de> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-12-19misc: move include files to include/qemu/Paolo Bonzini1-3/+3
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-19monitor: move include files to include/monitor/Paolo Bonzini1-1/+1
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-19ui: move files to ui/ and include/ui/Paolo Bonzini1-1/+1
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-11-03Merge branch 'trivial-patches' of git://github.com/stefanha/qemuBlue Swirl1-5/+0
* 'trivial-patches' of git://github.com/stefanha/qemu: pc: Drop redundant test for ROM memory region exec: make some functions static target-ppc: make some functions static ppc: add missing static vnc: add missing static vl.c: add missing static target-sparc: make do_unaligned_access static m68k: Return semihosting errno values correctly cadence_uart: More debug information Conflicts: target-m68k/m68k-semi.c
2012-11-01vnc: add missing staticBlue Swirl1-5/+0
Add missing 'static' qualifiers. Signed-off-by: Blue Swirl <blauwirbel@gmail.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2012-11-01pixman/vnc: use pixman images in vnc.Gerd Hoffmann1-4/+15
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: Gerd Hoffmann <kraxel@redhat.com>
2012-06-27Remove support for non-threaded VNC serverDaniel P. Berrange1-17/+0
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: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-03-14vnc: don't mess up with iohandlers in the vnc threadCorentin Chary1-0/+2
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: Corentin Chary <corentin.chary@gmail.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-02-10vnc: implement shared flag handling.Gerd Hoffmann1-0/+16
VNC clients send a shared flag in the client init message. Up to now qemu completely ignores this. This patch implements shared flag handling. It comes with three policies: By default qemu behaves as one would expect: Asking for a exclusive access grants exclusive access to the client connecting. There is also a desktop sharing mode which disallows exclusive connects (so one forgetting -shared wouldn't drop everybody else) and a compatibility mode which mimics the traditional (but non-conforming) qemu behavior. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2011-07-23Store VNC auth scheme per-client as well as per-serverDaniel P. Berrange1-0/+2
A future patch will introduce a situation where different clients may have different authentication schemes set. When a new client arrives, copy the 'auth' and 'subauth' fields from VncDisplay into the client's VncState, and use the latter in all authentication functions. * ui/vnc.h: Add 'auth' and 'subauth' to VncState * ui/vnc-auth-sasl.c, ui/vnc-auth-vencrypt.c, ui/vnc.c: Make auth functions pull auth scheme from VncState instead of VncDisplay Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-03-10vnc: Fix stack corruption and other bitmap related bugsStefan Weil1-3/+6
Commit bc2429b9174ac2d3c56b7fd35884b0d89ec7fb02 introduced a severe bug (stack corruption). bitmap_clear was called with a wrong argument which caused out-of-bound writes to the local variable width_mask. This bug was detected with QEMU running on windows. It also occurs with wine: *** stack smashing detected ***: terminated wine: Unhandled illegal instruction at address 0x6115c7 (thread 0009), starting debugger... The bug is not windows specific! Instead of fixing the wrong parameter value, bitmap_clear(), bitmap_set and width_mask were removed, and bitmap_intersect() was replaced by !bitmap_empty(). The new operation is much shorter and equivalent to the old operations. The declarations of the dirty bitmaps in vnc.h were also wrong for 64 bit hosts because of a rounding effect: for these hosts, VNC_MAX_WIDTH is no longer a multiple of (16 * BITS_PER_LONG), so the rounded value of VNC_DIRTY_WORDS was too small. Fix both declarations by using the macro which is designed for this purpose. Cc: Corentin Chary <corentincj@iksaif.net> Cc: Wen Congyang <wency@cn.fujitsu.com> Cc: Gerhard Wiesinger <lists@wiesinger.com> Cc: Anthony Liguori <aliguori@us.ibm.com> Signed-off-by: Stefan Weil <weil@mail.berlios.de> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-02-23vnc: add a non-adaptive optionCorentin Chary1-0/+1
This option allow to disable adaptive behaviors in some encodings. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-02-23vnc: use the new generic bitmap functionsCorentin Chary1-3/+4
Switch to bitmap.h and bitops.h instead of redefining our own bitmap helpers. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-02-23vnc: Add ZRLE and ZYWRLE encodings.Corentin Chary1-1/+26
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: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-02-23vnc: refresh lossy rect after a given timeoutCorentin Chary1-0/+3
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: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-02-23vnc: add a way to get the update frequency for a given regionCorentin Chary1-0/+19
This patch compute the update frequency (in Hz) for each 64x64 rects. Any adaptive encoding can get this value using vnc_update_freq(), and switch to a lossy encoding if the value is too high. The frequency is pre-calculated every 500ms, based on the last 10 updates per 64x64 rect. If a 64x64 rect was not updated in the last 2 second, then the frequency became 0, and all the stored timestamp are reseted. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-12-09vnc: support password expireGerd Hoffmann1-0/+1
This patch adds support for expiring passwords to vnc. It adds a new vnc_display_pw_expire() function which specifies the time when the password will expire. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2010-07-26vnc: threaded VNC serverCorentin Chary1-1/+52
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: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-07-26vnc: encapsulate encoding membersCorentin Chary1-26/+33
This will allow to implement the threaded VNC server in a more cleaner way. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-07-26vnc: tight add PNG encodingCorentin Chary1-1/+14
Introduce a new encoding: VNC_ENCODING_TIGHT_PNG [1] (-269) with a new tight filter VNC_TIGHT_PNG (0x0A). When the client tells it supports the Tight PNG encoding, the server will use tight, but will always send encoding pixels using PNG instead of zlib. If the client also told it support JPEG, then the server can send JPEG, because PNG will only be used in the cases zlib was used in normal tight. This encoding was introduced to speed up HTML5 based VNC clients like noVNC [2], but can also be used on devices like iPhone where PNG can be rendered in hardware. [1] http://wiki.qemu.org/VNC_Tight_PNG [2] http://github.com/kanaka/noVNC/ Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-07-26ui: move all ui components in ui/Corentin Chary1-0/+430
Move sdl, vnc, curses and cocoa UI into ui/ to cleanup the root directory. Also remove some unnecessary explicit targets from Makefile. aliguori: fix build when srcdir != objdir Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
generated by cgit v1.1 at 2024-11-01 03:38:40 +0000