summaryrefslogtreecommitdiffstats
path: root/client/windows
Commit message (Collapse)AuthorAgeFilesLines
...
* spice-win: handle multiple types on clipboard grab send & receiveArnon Gilboa2010-10-111-19/+36
|
* spice-win: remove clipboard_changer hackArnon Gilboa2010-10-111-9/+2
| | | | Instead of keeping a flag, we simply check wether the new owner is us or not
* spice-win: handle type VD_AGENT_CLIPBOARD_NONE in ↵Arnon Gilboa2010-10-111-1/+10
| | | | Platform::on_clipboard_notify()
* spice-win: remove windows-specific bitmap cut & paste supportArnon Gilboa2010-10-111-17/+0
| | | | will wait until png comes in
* spicec: Move setting of clipboard_owner to guest to platform codeHans de Goede2010-10-061-0/+7
| | | | | | | | | | | | | | Atleast under x11 there is a race condition when setting the clipboard owner to guest from the RedClient code rather then doing it in Platform. After the XSetSelectionOwner() in Platform::on_clipboard_grab(), which runs from the main message loop thread, the x11 event thread can receive a SelectionRequest event from another x11 app, before the RedClient code has set the clipboard owner, which will trigger the owner != guest check in the SelectionRequest event handling code. By moving the setting of the owner in to Platform::on_clipboard_grab() it gets protected by the clipboard lock, which closes this tiny race.
* spicec-x11: Force processing of ownerchange event when releasing the cbHans de Goede2010-10-041-0/+1
| | | | | | | | | | | | Make sure we process the XFixesSetSelectionOwnerNotify event caused by us setting the clipboard owner to none, directly after setting the owner to none. Otherwise we may end up changing the clipboard owner to none, after it has already been re-owned because the XFixesSetSelectionOwnerNotify event to owner none is event is still pending when we set the new owner, and then changes the owner back to none once processed messing up our clipboard ownership state tracking. I saw this happening when doing copy twice in succession inside the guest.
* Keep track of clipboard ownershipHans de Goede2010-10-021-0/+13
| | | | | | | | | | | | | Given that all clipboard handling is async, it is possible to for example receive a request for clipboard data from the agent while the client no longer owns the clipboard (ie a VD_AGENT_CLIPBOARD_RELEASE message is in transit to the agent). Thus it is necessary to keep track of our notion of clipboard ownership and check received clipboard messages (both from other apps on the client machine and from the agent) to see if they match our notion and if not drop, or in case were a counter message is expected nack the clipboard message.
* Rename platform clipboard handling functionsHans de Goede2010-10-021-4/+4
| | | | | | | | | | Rename the 4 platform clipboard functions which get called upon receival of an agent clipboard message to on_clipboard_* The old set_clipboard_* names were confusing as they suggest being a class property setter (like set_event_listener) rather then event handler, and set_clipboard_owner was causing a name conflict with the next patch in this series.
* Change VD_AGENT_CLIPBOARD_GRAB to an array of typesHans de Goede2010-10-011-5/+6
| | | | | | | A clipboard owner can indicate that it can supply the data the clipboard owns in multiple formats, so make the data passed with a VD_AGENT_CLIPBOARD_GRAB message an array of types rather then a single type.
* client: support clipboard/selection-owner model (v2)Arnon Gilboa2010-10-011-52/+212
| | | | | | | | | | | | | | | | | | | | | | | | | -includes most of Hans' review fixes (up to the SelectionRequest comment [4]) & X11 wips sent by Hans (10x!) -use the VD_AGENT_CLIPBOARD_* types in the platform code -add ifs for VD_AGENT_CAP_CLIPBOARD_BY_DEMAND in both sides -support the GRAB/REQUEST/DATA/RELEASE verbs in both ways -pasting clipboard data is now "only-by-demand" from both sides (client and agent), whose behavior is symmetric -client and agent don't read or send the contents of the clipboard unnecessarily (e.g. copy, internal paste, repeating paste, focus change) -set client as clipboard listener instead of application -add atexit(cleanup) in win platform linux: -instead of clipboard atom selection instead of XA_PRIMARY -enable USE_XRANDR_1_2 and support clipboard in MultyMonScreen -send utf8 with no null termination, remove ++size -add xfixes in configure.ac & Makefile.am windows: -bonus: support image cut & paste, currently only on windows not done yet: -clipboards formats are still uint32_t, not mime types stores as strings -platform_win is still used, not the root window -not replaced the ugly windows CF_DIB in agent/winclient
* client: add clipboard supportArnon Gilboa2010-07-191-0/+90
| | | | | | | | * windows - untested * linux - small strings both ways, large implemented differently: * client to guest - support INCR * guest to client - we supply a single possibly very large property * requires server changes in next patch to work with spice-vmc
* fix typo DisplayModeListner -> DisplayModeListenerAlon Levy2010-07-191-1/+1
|
* Disable tunnel by default on windowsAlexander Larsson2010-07-081-8/+0
|
* Make distcheck workAlexander Larsson2010-07-081-0/+39
|
* Make CEGUI optionalAlon Levy2010-07-011-2/+2
| | | | | This makes the CEGUI dependency optional and off by default. Restoring previous behaviour of exiting on disconnect if disabled.
* client: add --include "common.h" for generated marshallersYonit Halperin2010-06-292-2/+2
|
* Replace log4cpp with custom log functionAlexander Larsson2010-06-283-5/+6
| | | | | Also prints a simpler error to stderr for WARN or above so that we print something on the commandline if something go wrong.
* Make pointers 32bit in new protocol formatAlexander Larsson2010-06-231-2/+2
|
* Generate marshaller/demarshallers for old protocolAlexander Larsson2010-06-223-12/+42
|
* applying zlib compression over glz on WAN connectionYonit Halperin2010-06-211-2/+10
|
* Make opengl optional, disabled by defaultAlexander Larsson2010-06-211-8/+0
| | | | | | | | | | The OpenGL renderer isn't really useful right now, its not quite up to date, its not really faster than software and it only supports a limited subset of drivers. So, lets disable it for now. Long term opengl rendering of the 2d part of spice is important if we want to combine 2d and 3d rendering (say if spice adds opengl support in the protocol). But until then this is isn't useful for normal use.
* Make generated marshallers build on win32Alexander Larsson2010-06-182-8/+23
|
* Generate demarshalling code on win32 tooAlexander Larsson2010-06-181-13/+50
|
* Client: Use the autogenerated demarshallersAlexander Larsson2010-06-181-2/+2
| | | | | | | | | | | | | | | | When a message has been read from the network we now pass it into the generated demarshaller for the channel. The demarshaller converts the network data to in-memory structures that is passed on to the spice internals. Additionally it also: * Converts endianness * Validates sizes of message and any pointers in it * Localizes offsets (converts them to pointers) * Checks for zero offsets in messages where they are not supported Some of this was previously done using custom code in the client, this is now removed.
* JPEG support: introducing jpeg encoding for spice bitmapsYonit Halperin2010-06-091-0/+8
|
* Remove all mentions of "cairo" from the codeAlexander Larsson2010-05-032-10/+10
| | | | | The command line option is renamed from "cairo" to "sw", and similarly all filenames and types from Cairo to Sw (and similar).
* client: Report window format right for win32Alexander Larsson2010-04-292-4/+14
|
* client: Support 16bpp pixmaps on win32Alexander Larsson2010-04-292-6/+33
|
* Fix up win32 client with recent changesAlexander Larsson2010-04-232-1/+10
|
* Client: Support pixmap format conversion in copy_pixelsAlexander Larsson2010-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | In order to be able to support 16bit canvases on 32bit screens and 32bit canvases on 16bit screens we need to handle format conversion when drawing RedPixmaps. The way this works now for X11 is that we only have one PIXELS_SOURCE_TYPE for pixmaps, which always has a pixman_image_t for the data, but additionally it has an XImage (shared mem or not) if the screen the pixmap was created for (i.e. an explicit one or the default screen) has the same format as the pixmap. When we draw a pixmap on a drawable we have two variants. If the pixmap has a XImage and it matches the format of the target drawable then we just X(Shm)PutImage it to the drawable. If the formats differ, then we create a temporary XImage and convert into that before drawing it to the screen. Right now this is a bit inefficient, because we always allocate a new temporary image when converting. We want to add some caching here, but at least this lets things work again.
* Move RedPixmap::Format to RedDrawable::FormatAlexander Larsson2010-04-233-9/+9
| | | | | | | | We need to know the format for other drawables too (like for instance the native format of a window), so we're pushing this down. This changes a bunch of references to be RedDrawable::, but not all. The the old RedPixmap:: references still work, but will be phased out.
* Make client canvas and pixmaps handle more formats and simplifyAlexander Larsson2010-04-233-29/+20
| | | | | | | | | | | We now support 16bit format pixmaps as well as the old ones. Including both 555 and 565 modes. We drop the palette argument for pixmap construction as it was only used for black/white anyway. Canvas creation is simplified so that there is no separate set_mode state. Canvases are already created in the right mode and never change.
* Add emacs modelines to more filesAlexander Larsson2010-04-232-0/+2
|
* Relicense everything from GPL to LGPL 2.1+Alexander Larsson2010-04-1323-207/+207
|
* Use upstream name for pthreads lib and new freetype versionAlexander Larsson2010-04-121-2/+2
|
* spice: win32 client: fix gdi lockingIzik Eidus2010-04-094-11/+11
| | | | | | | | | | | While the fix could have been more effective, it seems like this patch stream better with the coding logic that was there..., maybe later we will want to change the locking into more effective way. (There is just the primary surface to protect in reiality) Signed-off-by: Izik Eidus <ieidus@redhat.com>
* Use libjpeg to decode mjpegs, not ffmpegAlexander Larsson2010-04-081-4/+12
| | | | | | | | | | | | | | | | | | This is pretty straightforward, although there are two weird issues. The current encoder has two bugs in the yuv conversion. First of all it switches red and blue, due to something of an endianness issue. We keep this behavior by switching red and blue. Maybe we want to change this in the new protocol version since switching this may cause jpeg compression to be worse. Secondly, the old coder/decoder did rgb to/from yuv420 wrongly for jpeg, not using the "full scale" version of Y that is used in jpeg, but the other one where y goes from 16 to 235. (See jpeg/jfif reference on http://en.wikipedia.org/wiki/YCbCr for details.) The new decoder uses the full range in order to get better quality, which means old encoders will show slightly darker images. This completely removes all ffmpeg usage in the client
* Update project file to visual studio 2008Alexander Larsson2010-04-082-9/+8
|
* New memory allocators that exit on OOM and handle multiplication overflowAlexander Larsson2010-03-111-0/+4
| | | | | | | | | Every place that does a regular malloc/calloc and aborts on failure should use spice_malloc/spice_mallo0 instead, which is leaner and cleaner. Allocations of dynamically sized arrays can use g_malloc_n or g_new etc which correctly handle multiplication overflow if some of the arguments are not trusted.
* Use macros from <spice/macros.h> rather than duplicate themAlexander Larsson2010-03-091-1/+1
|
* Fix up win32 build reference to pixman_utils.cppAlexander Larsson2010-03-051-1/+1
| | | | It was pointing to the wrong directory for pixman_utils.cpp
* Update visual studio project for pixman changesLarsson@.(none)2010-03-011-4/+12
|
* Remove no longer needed CAIRO_CANVAS_CACH_IS_SHARED define and codeAlexander Larsson2010-02-231-2/+2
|
* Use the new header namesAlexander Larsson2010-02-041-1/+1
| | | | | | I just ran: find -name "*.[ch]" | xargs sed -i -f ../spice-protocol/includes.sed find -name "*.cpp" | xargs sed -i -f ../spice-protocol/includes.sed
* Rename symbols that were changed in spice-protocolAlexander Larsson2010-02-044-51/+51
| | | | | | This is an automatic change using: $ find -name "*.[ch]" | xargs ../spice-protocol/rename-identifiers.sh ../spice-protocol/renames $ find -name "*.cpp" | xargs ../spice-protocol/rename-identifiers.sh ../spice-protocol/renames
* client: add Platform::term_printfYaniv Kamay2010-01-112-26/+66
| | | | | | Platform::term_printf is a variant of printf that on windows dynamically opens console in order to have visible output during command line processing.
* client: move log file to spicec appdata dirYaniv Kamay2010-01-111-6/+11
|
* server,client: server authentication for secured channels.Yonit Halperin2010-01-111-0/+19
| | | | | | | | | 3 available mechanisms: by public key, by host name, and by certificate subject name. In the former method, chain of trust verification is not performed. The CA certificate files are looked for under <spice-config-dir>/spice_truststore.pem windows <spice-config-dir>=%APPDATA%\spicec\ linux <spice-config-dir>=$HOME/.spicec/
* spice: menu additonsArnon Gilboa2010-01-071-4/+12
| | | | | | -functions: set_name, remove_command, remove_sub, clear -item state & enum -add state support in RedWindow insert_command & insert_menu
* spice: add missing breakArnon Gilboa2010-01-061-0/+1
|
generated by cgit (git 2.34.1) at 2024-11-13 00:12:37 +0000