summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* server: use -std=c99Alon Levy2011-03-221-0/+1
| | | | Finds some bugs.
* python_modules/codegen.py: fix indent error in an unused functionAlon Levy2011-03-221-1/+1
|
* client/smartcard: use proper include delemitersAlon Levy2011-03-221-4/+4
|
* client: Don't handle hotkeys while sticky alt is activeHans de Goede2011-03-111-4/+6
| | | | | | | | | | | | | | | | | In some cases rhev-m changes the hotkey for releasing the mouse grab to ctrl + alt. This makes it impossible to send ctrl + alt + other-key to the guest, even when using sticky alt. What happens is: -press alt until sticky alt activates -release alt (but recorded state stays pressed due to sticky alt) -press ctrl -hotkey code sees ctrl+alt pressed, releases mouse grab -mouse grab release code does an unpress all -> end of sticky state. This patch makes it possible to atleast send ctrl + alt + del (or other key) using sticky alt. Note: even with this patch it is still a bad idea to use ctrl + alt as hotkey combi.
* server/reds: allow call to reds_agent_remove even if it is goneAlon Levy2011-03-081-1/+3
| | | | | | | | | | | | | | | | | | | | | The current assert(reds->agent_state.connected) tiggers if when the agent disconnected there was still data waiting to be sent (for instance if there is a bug in the client handling clipboard and it is killed while a large clipboard transfer is in progress). So first call to reds_agent_remove happens from spice_server_char_device_remove_interface, and then it is called again (triggering the assert) from free_item_data from read_from_vdi_port because of the channel destruction. Other option would be to not call it from one of the paths - but that is suboptimal: * if there is no data in the pipe, the second call never happens. * the second call has to be there anyway, because it may fail during parsing data from the agent. This patch fixes a segfault on this assert when a client starts passing from guest agent to client a large clipboard and dies in the middle. There is still another assert happening occasionally at marshaller which I don't have a fix for (but it doesn't seem to be related).
* client/smartcard: handle the --smartcard-db optionAlon Levy2011-03-081-1/+4
|
* client/windows: cleanup vcproj based on updated libsArnon Gilboa2011-03-081-8/+8
| | | | | | | | | | | | | | | | using updated windows libraries: http://www.spice-space.org/download/stable/wspice-x86_08032011.zip http://www.spice-space.org/download/stable/wspice-x64_08032011.zip -remove IgnoreDefaultLibraryNames="MSVCRT.lib", since pixman is now compiled using MT threading model similar to other libraries. It used to be mistakenly compiled with MD. -downgrade freetype lib to 2.3.11-7, which is the one used/tested with CEGUI 0.6.2 -pthread lib patched (InterlockedCompareExchange), so x64 client will no longer crash on SelectClipRgn, BitBlt etc.
* server/input: avoid double free() of RedChannel on disconnectMarc-André Lureau2011-03-031-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current master is calling red_channel_destroy() on incoming error, but reds Channels still references it, which causes a double free() later on (see valgrind report below). Instead, on error condition, do like the rest of the channels and call reds_disconnect(), which remove the references and call shutdown(), which then call red_channel_destroy() and finally free the channel with red_channel_destroy(). Note: the previous code intention was certainly to be able to keep the rest of the channels connected when input channel has errors. This is not addressed by this patch. red_channel_shutdown: ==29792== Invalid read of size 8 ==29792== at 0x4C6F063: red_channel_shutdown (red_channel.c:460) ==29792== by 0x4C51EFA: inputs_shutdown (inputs_channel.c:463) ==29792== by 0x4C48445: reds_shatdown_channels (reds.c:539) ==29792== by 0x4C4868A: reds_disconnect (reds.c:603) ==29792== by 0x4C519E9: main_channel_on_error (main_channel.c:765) ==29792== by 0x4C6E80A: red_channel_peer_on_incoming_error (red_channel.c:215) ==29792== by 0x4C6E22D: red_peer_handle_incoming (red_channel.c:87) ==29792== by 0x4C6E551: red_channel_receive (red_channel.c:154) ==29792== by 0x4C6F329: red_channel_event (red_channel.c:531) ==29792== by 0x41CB8C: main_loop_wait (vl.c:1365) ==29792== by 0x437CDE: kvm_main_loop (qemu-kvm.c:1589) ==29792== by 0x41FE9A: main (vl.c:1411) ==29792== Address 0x30b0f6d0 is 0 bytes inside a block of size 28,648 free'd ==29792== at 0x4A05372: free (vg_replace_malloc.c:366) ==29792== by 0x4C6F032: red_channel_destroy (red_channel.c:454) ==29792== by 0x4C6E80A: red_channel_peer_on_incoming_error (red_channel.c:215) ==29792== by 0x4C6E22D: red_peer_handle_incoming (red_channel.c:87) ==29792== by 0x4C6E551: red_channel_receive (red_channel.c:154) ==29792== by 0x4C6F329: red_channel_event (red_channel.c:531) ==29792== by 0x41CB8C: main_loop_wait (vl.c:1365) ==29792== by 0x437CDE: kvm_main_loop (qemu-kvm.c:1589) ==29792== by 0x41FE9A: main (vl.c:1411) https://bugs.freedesktop.org/show_bug.cgi?id=34971
* Revert "server/red_channel: red_channel_event: push on blocked"Marc-André Lureau2011-03-031-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 5062433d8af45822371b6487a8d7baea23071d18. red_channel_receive() can call red_channel_destroy() which frees channel. The condition bellow is then checked, which can access a freed channel: if (event & SPICE_WATCH_EVENT_WRITE || channel->send_data.blocked) Reverting this commit solves the issue without any apparent bugs/drawbacks, which kind of clears out the weird TODO. handle_dev_input: cursor connect ==11826== Invalid read of size 4 ==11826== at 0x4C6F83C: red_channel_event (red_channel.c:535) ==11826== by 0x41CB8C: main_loop_wait (vl.c:1365) ==11826== by 0x437CDE: kvm_main_loop (qemu-kvm.c:1589) ==11826== by 0x41FE9A: main (vl.c:1411) ==11826== Address 0x31fb00f0 is 96 bytes inside a block of size 28,648 free'd ==11826== at 0x4A05372: free (vg_replace_malloc.c:366) ==11826== by 0x4C6F536: red_channel_destroy (red_channel.c:453) ==11826== by 0x4C52B5D: inputs_channel_on_incoming_error (inputs_channel.c:449) ==11826== by 0x4C6ED0E: red_channel_peer_on_incoming_error (red_channel.c:215) ==11826== by 0x4C6E731: red_peer_handle_incoming (red_channel.c:87) ==11826== by 0x4C6EA55: red_channel_receive (red_channel.c:154) ==11826== by 0x4C6F82D: red_channel_event (red_channel.c:530) ==11826== by 0x41CB8C: main_loop_wait (vl.c:1365) ==11826== by 0x437CDE: kvm_main_loop (qemu-kvm.c:1589) ==11826== by 0x41FE9A: main (vl.c:1411) ==11826== https://bugs.freedesktop.org/show_bug.cgi?id=34971
* server/red_worker: use red_channel_pipe_item_initAlon Levy2011-03-022-30/+38
| | | | replaces in file red_pipe_item_init.
* server/red_channel: move out_bytes_counter from Outgoing to RedChannelAlon Levy2011-03-023-7/+17
|
* server/red_channel: split Incoming/Outgoing to callback and stateAlon Levy2011-03-022-42/+57
| | | | | | | | This allows later to have the callback table under RedChannel when the callbacks actually get used by RedChannelClient. Since the cb's are identical for different clients of the same channel it makes sense to store the callback pointers in one place per channel. The rest of the incoming and outgoing struct just gets moved to RedChannelClient.
* server/red_channel: no opaque in red_channel_peer_on_*_errorAlon Levy2011-03-021-8/+4
|
* server/red_worker: use red_channel_is_connectedAlon Levy2011-03-021-3/+3
|
* server/red_channel: add red_channel_disconnect, use in red_workerAlon Levy2011-03-023-15/+12
| | | | replace channel_release_res in red_worker with red_channel_disconnect.
* server/red_channel: reset send_data.item to NULL after releaseAlon Levy2011-03-021-0/+1
|
* server/red_worker: remove RedChannel argument from add_buf_from_infoAlon Levy2011-03-021-4/+4
| | | | It was unused.
* server/red_channel: add red_channel_{,no_}item_being_sentAlon Levy2011-03-023-7/+26
|
* server/red_worker: complete removal of send_data.marshaller useAlon Levy2011-03-021-23/+28
|
* server/red_worker: replace _send_ functions by _marshall_Alon Levy2011-03-021-111/+76
| | | | | | | | | | Changes in display channel for a code size win. A note about this and the previous cursor change: it will appear that we are now (with these changes) releasing resources too early. This is not so - send always has the option of blocking, which means after send you can not release resources anyway, that's what the release_item callback is for. So both the code before and now are doing the same accounting.
* server/red_channel: add red_channel_send_message_pendingAlon Levy2011-03-023-1/+9
|
* server/red_channel: add red_channel_all_blockedAlon Levy2011-03-023-5/+21
|
* server/red_worker: cursor channel: replace _send_ with _marshall_Alon Levy2011-03-021-31/+23
|
* server/red_channel (all): add red_channel_get_headerAlon Levy2011-03-022-0/+12
| | | | | This is useful during the channel specific channel_send_pipe_item_proc callback, it allows altering or reader the header being sent.
* server/red_channel: add red_channel_get_first_socketAlon Levy2011-03-023-4/+15
| | | | | | Use in main_channel. This is just for backward portability later when multiple clients are introduced - needs to be considered (which sockets do we want to export from libspiceserver?)
* server/red_channel (+): remove red_channel_add_bufAlon Levy2011-03-025-60/+55
|
* server/tunnel: pass SpiceMarshaller reference from sendAlon Levy2011-03-021-54/+37
| | | | | | | | Introduce SpiceMarshaller param to all send's that do add_buf Next patch will use marshaller in all functions that currently don't by replacing red_channel_add_buf with marshaller add_ref. Note - currently tunnel is broken due to wrong size in messages.
* server/red_channel (all): add red_channel_get_streamAlon Levy2011-03-025-7/+19
| | | | | use in config_socket, this makes the stream internal to the RedChannel implementation that will change later for multiple client support.
* ring: add RING_FOREACH{,_SAFE,_REVERSED}Alon Levy2011-03-021-0/+21
|
* server/common: introduce common/spice_common.hAlon Levy2011-03-022-45/+71
| | | | | | move all the ASSERT/PANIC/PANIC_ON/red_error/red_printf* macros to a common file to be used with ring.h that is going to be used externally (by spice-gtk).
* server/red_channel (all): handle MIGRATE_DATA and MIGRATE_FLUSH_DATAAlon Levy2011-03-027-52/+169
| | | | | | | | | | Handling done in red_channel instead of per channel, using call backs for the channel specific part. Intended to reduce furthur reliance of channels on RedChannel struct. The commit makes the code harder to understand because of the artificial get_serial stuff, should later be fixed by having a joint migration header with the serial (since all channels pass it).
* server/red_channel (all): add red_channel_get_marshallerAlon Levy2011-03-025-174/+205
| | | | | | | For ussage in the send_item callback. It's only valid during this time anyway (should make it return NULL in other occasions?) No more direct usage of RedChannel.send_data.marshaller by channels.
* server/red_worker: use red_channel_destroyAlon Levy2011-03-021-2/+1
|
* server/inputs_channel: s/PIPE_ITEM_INIT/PIPE_ITEM_INPUTS_INIT/Alon Levy2011-03-021-3/+3
|
* server/red_channel: move SET_ACK to red_channelAlon Levy2011-03-024-52/+43
|
* server/red_channel: add more ack apiAlon Levy2011-03-023-7/+18
|
* server: use red_channel_get_message_serialAlon Levy2011-03-022-9/+4
|
* server/red_channel (all): makes red_channel_reset_send_data privateAlon Levy2011-03-027-24/+34
| | | | ready the way for handling ack messages in RedChannel.
* server/red_worker: use red_channelAlon Levy2011-03-021-406/+40
|
* server/red_channe: make hold_item take a channel argAlon Levy2011-03-026-6/+6
|
* server/red_worker: introduce red_peer_handle_outgoing and OutgoingHandlerAlon Levy2011-03-021-36/+115
| | | | From red_channel.
* server/red_worker: introduce common_channel_config_socketAlon Levy2011-03-021-20/+30
|
* server/red_worker: line width fixAlon Levy2011-03-021-1/+1
|
* server/red_worker: don't push to NULL channel (called from device input)Alon Levy2011-03-021-1/+4
|
* server/red_worker: introduce red_channel_pipe_clearAlon Levy2011-03-021-59/+18
| | | | No more common_release_pipe_item
* server/red_worker: add red_channel_pushAlon Levy2011-03-021-24/+30
|
* server/red_worker: add send_itemAlon Levy2011-03-021-3/+11
|
* server/red_worker: red_channel renamesAlon Levy2011-03-022-59/+59
| | | | | | | | | | | | | The renames are part of refactoring red_worker's RedChannel to reuse red_channel.h's RedChannel at the end. s/red_send_data/red_channel_send/ s/red_pipe_get/red_channel_pipe_get/ s/recive_data/incoming/ s/red_receive/red_channel_receive/ s/channel_handle_message/red_channel_handle_message/ s/channel_is_connected/red_channel_is_connected/ s/red_pipe_add_type/red_channel_pipe_add_type/
* server/red_tunnel_worker: use message_serial setter and getterAlon Levy2011-03-021-2/+2
| | | | fixes breakage in --enable-tunnel compilation.
* x11: Use _exit rather then exit on X errors (rhbz#680763)Hans de Goede2011-03-011-2/+2
| | | | | | | This avoids us trying to restore the original resolution when we're fullscreen and an X error happens. As restoring fullscreen is a bad idea then as this involves making more X calls, which can get us stuck (in side an XLockDisplay call for example).