summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Replace epoll with select in X clientAlexander Larsson2010-10-122-218/+97
| | | | | | | | The use of epoll in the client is totally overkill in terms of scalability, and its a problem for portability. The OSX port converts this to use select, but keeps some of the old complexities in the code. This new patch makes it simpler and look much more like the windows code.
* server: add channel notifications.Gerd Hoffmann2010-10-123-4/+48
| | | | | | | | | | | | | This patch adds a channel event callback to the spice core interface. This new callback will be called for three events: (1) A new connection has been established. (2) The channel is ready (i.e. authentication is done, link message verification passed all tests, channel is ready to use). (3) Channel was disconnected. Qemu will use this to send notifications to the management app.
* spicec-x11: Put locks around xlib calls which wait for a replyHans de Goede2010-10-114-44/+314
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since libX11-1.3.4 the multi-threading handling code of libX11 has been changed, see: http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=933aee1d5c53b0cc7d608011a29188b594c8d70b This causes several issues. One of them is the display inside the client not getting updated when there are no XEvents being generated, this is caused by the following part of the referenced commit message: Caveats: - If one thread is waiting for events and another thread tries to read a reply, both will hang until an event arrives. Previously, if this happened it might work sometimes, but otherwise would trigger either an assertion failure or a permanent hang. We were depending on the otherwise behavior and apparently were lucky. This can be seen by starting F14 in runlevel 3 and then doing startx and not touching the mouse / keyb afterwards. Once you move the mouse (generate an event you see the UI contents being updated but not before. Another thing both I and Alon (iirc) have seen are hangs where 2 threads are stuck in XSync waiting for a reply simultaneously. This might be related to libxcb version, according to the libX11 commit a libxcb newer then 1.6 was needed, and my system had 1.5 at the time I saw this after updating to libxcb 1.7 I can no longer reproduce. This patch tackles both problems (and is needed for the 1st one indepently of the 2nd one possibly being fixed) by adding XLockDisplay calls around all libX11 calls which wait for a reply or an event.
* 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: Do not try to do accounting of pci memoryHans de Goede2010-10-093-40/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this patch spicec reproducely hangs in GlzDecoderWindow::pre_decode_update_window(). When GlzDecoderWindow::will_overflow() returns true, GlzDecoderWindow::pre_decode_update_window(), waits for a call to GlzDecoderWindow::post_decode() to free up some memory This happens even though there still is pci memory available (otherwise the driver would not have been able to send an image to decode in the first place). The GlzDecoderWindow::post_decode() call never happens as the server is waiting for a reply to the decode of the hanging image, causing the client to hang for ever. This patch fixes this by simply removing the "attempted" pci memory accounting. As there is no need for that, as the driver already must keep track of pci memory usage. I've verified that both the old and new Xorg drivers take care of not overusing the pci memory themselves I would expect the same to be true for the windows driver. Note the calculating of the glz_window_size in red_client.cpp cannot be removed as the calculated value is send as part of the SpiceMsgcDisplayInit on connect.
* spicec: only send display-config if the agent can handle itHans de Goede2010-10-061-2/+3
|
* spicec-x11: Drop annoying useless warningHans de Goede2010-10-061-1/+0
| | | | | | Every time an events comes past where the Window is None (which happens about once every 5 minutes or so), this annoying "invalid window" message gets printed. Remove it!
* spicec: don't send agent messages directly from ClipboardListener callbacksHans de Goede2010-10-062-6/+59
| | | | | | | | ClipboardListener callbacks can run from another thread then the main channel loop thread, where agent messages are normally dispatched from. So they may not send agent messages directly, instead they should post events to the main channel loop.
* spicec-x11: Remove a race window in selection ownership release codeHans de Goede2010-10-061-0/+8
| | | | | | | | | | | Well almost remove it, it was possible that another x11 app would acquire selection ownership, and we would receive a release message from the agent before having processed the xselection ownership change event. Then we would set the selection owner to none, overriding the new owner. As the comment in the patch indicates there still is a minute window left where something similar can happen after this patch. Nothing we can do about that (I blame the libX11 selection API).
* spicec: Move setting of clipboard_owner to guest to platform codeHans de Goede2010-10-064-3/+17
| | | | | | | | | | | | | | 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: make get_clipboard_type handle the None AtomHans de Goede2010-10-041-0/+3
|
* spicec-x11: protect against recursive incr propertiesHans de Goede2010-10-041-0/+4
|
* spicec-x11: If the clipboard was large return the memory to the systemHans de Goede2010-10-041-1/+8
|
* spicec-x11: use malloc / free / realloc for clipboard dataHans de Goede2010-10-041-19/+7
| | | | | | As we need a realloc function it is better to use malloc / free / realloc then to diy, esp. as realloc can grow the buffer without needing a memcpy.
* spicec-x11: Use a queue for XSelectionRequest eventsHans de Goede2010-10-041-59/+119
| | | | | | | | | | | XSelectionRequest events must be answered in the order they were received. But for TARGETS request we can answer directly, where as other requests need to go through the agent. This causes us to handle things out of order, and this can cause us to have more then one requets outstanding with the agent, which is also not what we want. So this patch introduces a queue for XSelectionRequest events, causing us to handle them 1 at a time and always in order.
* spicec-x11: handle multiple types per grabHans de Goede2010-10-041-55/+99
| | | | | And also handle many x11 targets (ie utf8 variants) to a single agent type mapping.
* spicec-x11: Add XFlush calls were neededHans de Goede2010-10-041-0/+10
| | | | | | | | Since we do not always "pump" libX11's event loop by calling XPending (we only call XPending when there is data to read from the display fd), we must always explictly flush any outstanding requests. This patch adds a whole bunch of missing XFlush calls.
* spicec-x11: Force processing of ownerchange event when releasing the cbHans de Goede2010-10-043-2/+15
| | | | | | | | | | | | 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.
* spicec-x11: Request targets from new clipboard ownerHans de Goede2010-10-041-123/+240
| | | | | | | | | | | | | | | Request targets from new clipboard owner, rather then assuming UTF-8 (not entirely complete yet, the last pieces will be in another patch). Atleast as important this code unifies the selection getting code for incr and non incr getting of selection data so that it can be used for both getting regular selection data and for getting targets selection data. This also fixes a big bug in the (I believe untested sofar) incr support code which was interpreting the contents of PropertyNotify events as XSelectionEvents rather then as XpropertyEvents which are completely differen structs!
* spicec-x11: remove clipboard_changer hackHans de Goede2010-10-031-19/+21
| | | | | | | Instead of keeping a flag, we can and should simply check wether the new owner reported in the event it us or not. Also check for the new owner being none and send a clipboard_release when that is the case (through set_clipboard_owner(owner_none)).
* Keep track of clipboard ownershipHans de Goede2010-10-025-0/+73
| | | | | | | | | | | | | 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-024-16/+16
| | | | | | | | | | 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.
* Move checking for on demand clipboard cap closer to sending of agent messagesHans de Goede2010-10-021-8/+10
| | | | | | | | | | This way the events will always get generated and other things (such as clipboard ownership administration, see the next patches) can be done in repsonse to the events, even though no message will be send. This patch also removes the !_agent_caps check from the capability checks, this is not needed as VD_AGENT_HAS_CAPABILITY checks _agent_caps_size which will be 0 when _agent_caps is NULL.
* Respond to clipb request with an unsupported type with data with a none typeHans de Goede2010-10-011-1/+1
| | | | | | | | | Currently we send a VD_AGENT_CLIPBOARD_RELEASE when we receive a VD_AGENT_CLIPBOARD_REQUEST with a type which we do not support. This is not correct, as this means given up clipboard ownership while we may be able to answer requests with different types. The correct response is to nack the request by sending a VD_AGENT_CLIPBOARD (data) message with a type of VD_AGENT_CLIPBOARD_NONE.
* Change VD_AGENT_CLIPBOARD_GRAB to an array of typesHans de Goede2010-10-015-20/+34
| | | | | | | 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.
* Call intern_atoms() earlierHans de Goede2010-10-011-2/+2
| | | | | We call XFixesSelectSelectionInput with the clipboard_atom, so we musr initialize the atoms before calling XFixesSelectSelectionInput.
* Set clipboard_event before calling send_selection_notifyHans de Goede2010-10-011-1/+1
| | | | | send_selection_notify used the clipboard_event, so set it before calling send_selection_notify.
* wrap XGetAtomNameHans de Goede2010-10-011-1/+9
| | | | | XGetAtomName() throws X11 errors when called on a None atom, so wrap it catching the None case.
* client: support clipboard/selection-owner model (v2)Arnon Gilboa2010-10-019-266/+602
| | | | | | | | | | | | | | | | | | | | | | | | | -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
* Bump version to 0.6.10.6.1Alexander Larsson2010-09-291-1/+1
|
* Update NEWS for releaseAlexander Larsson2010-09-291-0/+8
|
* client: Avoid crash if platform_win is NULLAlexander Larsson2010-09-291-2/+6
| | | | | This is a temporary fix as this will be fixed for real when the cut and paste patches land.
* client: Re-enable USE_XRANDR_1_2Alexander Larsson2010-09-291-1/+1
| | | | This was disabled by mistake before.
* client: Don't hardcode -lrtAlexander Larsson2010-09-291-2/+1
| | | | | -lrt is already included in SPICE_NONPKGCONFIG_LIBS if needed so no need to add it to the command line manually.
* client: Fall back to gettimeofday if clock_gettime not foundAlexander Larsson2010-09-293-1/+20
|
* client: Include config.h from common.hAlexander Larsson2010-09-295-10/+4
| | | | | config.h should be availible everywhere, so move its inclusion to the top of common.h.
* client: Check for pthread yield function using autoconfAlexander Larsson2010-09-292-1/+21
|
* Initialize variable to avoid compiler warningAlexander Larsson2010-09-291-1/+1
| | | | Seems the OSX gcc warns on saveRight not being initialzied.
* client: Include stdint.h for uint32_tAlexander Larsson2010-09-291-0/+2
|
* client: Don't use basename for argv[0] in --help outputAlexander Larsson2010-09-291-17/+1
| | | | | This isn't what other apps do, and it had issues in the OSX port, so just remove this.
* Fix warning from OSX compilerAlexander Larsson2010-09-291-4/+1
| | | | | The OSX compiler warns about uninitialized variable, so we change a bit how size is initialized.
* Handle surface images in DrawOpaqueAlexander Larsson2010-09-221-19/+42
|
* server: Handle self_image in localize_bitmapAlexander Larsson2010-09-211-9/+16
| | | | | | When drawing a drawable with a NULL src bitmap that means we should be using the previously generated self_bitmap. Not doing this causes a segfault due to accessing the NULL.
* server: Handle NULL image in red_update_streamableAlexander Larsson2010-09-211-1/+2
| | | | A NULL src bitmap means self_bitmap, which is not a stream, so abort.
* server: Use the right image size for self_bitmapAlexander Larsson2010-09-211-2/+2
| | | | | | | The self_bitmap is the size of self_bitmap_area, not the bbox. This is especially important since we later copy the self_bitmap_area into the new bitmap, and if that is larger than bbox then we will overwrite random memory.
* server: Don't leak QUIC image chunksAlexander Larsson2010-09-211-0/+3
| | | | | red_put_image() needs to free the chunks for QUIC images, as we allocate these when creating the image.
* Fix crash when resetting pixman image transformAlexander Larsson2010-09-211-1/+2
| | | | | Resetting the transform is done by setting it to the identity transform, not passing in NULL. Passing in NULL causes a crash.
generated by cgit (git 2.34.1) at 2024-11-12 06:24:31 +0000