summaryrefslogtreecommitdiffstats
path: root/server/inputs_channel.c
Commit message (Collapse)AuthorAgeFilesLines
* red_channel: monitor connection latency using MSG_PINGYonit Halperin2013-04-221-0/+1
|
* inputs-channel: Don't send insecure keyb notify to in migrate clientHans de Goede2013-03-151-1/+1
| | | | | | | This fixes spice-gtk printing message like these on migration: (remote-viewer:18402): GSpice-CRITICAL **: spice_channel_iterate_read: assertion `c->state != SPICE_CHANNEL_STATE_MIGRATING' failed Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* inputs-channel: Handle printing of insecure keyboard notifyHans de Goede2013-03-151-0/+6
| | | | | | | | | This is clearly something which should be handled in the inputs_channel code, rather then having a special case for it in the generic channel handling code in reds.c. Moving it here also fixes the TODO we had on only sending this message to new clients. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* inputs_channel: Fix wrong handling of key up/down on big endianHans de Goede2012-10-181-5/+7
| | | | | | | | | The client will send 0x000000## codes for regular keys, and 0x0000##e0 codes for extended keys. The current code which simply walks the uint32_t code in memory order relies on the memory order being little endian, which will clearly fail on big endian machines, this fixes this. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server/inputs_channel.c: whitespace fixYonit Halperin2012-08-301-1/+1
|
* inputs: handle SPICE_MSGC_INPUTS_KEY_SCANCODEMarc-André Lureau2012-08-271-0/+10
| | | | | Handle SPICE_MSGC_INPUTS_KEY_SCANCODE message, allowing arbitrary keyboard scancode sequence.
* inputs channel migration: don't send any msg after MSG_MIGRATEYonit Halperin2012-08-271-5/+25
| | | | | Pending motion acks, and keyboard modifiers messages will be sent by the destination after receiving the migration data.
* inputs_channel: send and handle migration dataYonit Halperin2012-08-271-3/+49
|
* red_channel: remove unused migrate flag from RedChannelYonit Halperin2012-08-271-1/+0
| | | | The relevant flags reside in RedChannelClient and RedClient
* inputs channel: use the default red_channel behaviour for client_cbs.migrateYonit Halperin2012-08-271-7/+0
| | | | The default callback sends SPICE_MSG_MIGRATE to the client.
* inputs channel: fix using spice messages enums as pipe items typeYonit Halperin2012-08-271-13/+11
| | | | | | A channel pipe item type must start from PIPE_ITEM_TYPE_CHANNEL_BASE. SPICE_MSG_MIGRATE value eq. PIPE_ITEM_TYPE_SET_ACK. Setting a pipe item type to SPICE_MSG_MIGRATE, leads to red_channel handling PIPE_ITEM_TYPE_SET_ACK.
* red_channel: handle sending SPICE_MSG_MIGRATEYonit Halperin2012-08-271-1/+2
| | | | | | | The relevant code is common to all channels. The patch also contains a fix to the return value for handle_migrate_data callback: s/uint64_t/int
* server: handle red_channel_client_create returning NULLYonit Halperin2012-05-211-0/+3
|
* Use the spice-common logging functionsMarc-André Lureau2012-03-251-17/+17
| | | | | It will abort by default for critical level messages. That behaviour can be tuned at runtime.
* Use the spice-common submoduleMarc-André Lureau2012-03-251-2/+4
| | | | | | | | | | | | | | | | | | This patch will replace the common/ directory with the spice-common project. It is for now a simple project subdirectory shared with spice-gtk, but the goal is to make it a proper library later on. With this change, the spice-server build is broken. The following commits fix the build, and have been seperated to ease the review. v2 - moves all the generated marshallers to spice-common library - don't attempt to fix windows VS build, which should somehow be splitted with spice-common (or built from tarball only to avoid generation tools/libs deps) v3 - uses libspice-common-client - fix a mutex.h inclusion reported by Alon
* server: don't fail on ENOPROTOOPT from setsockoptNahum Shalman2012-03-121-1/+1
| | | | | | If we allow listening on arbitrary sockets like unix sockets, we can get ENOPROTOOPT errors from setsockopt calls that set TCP specific options. This should be allowed to happen.
* Ensure all members of ChannelCbs and ClientCbs are either assigned or NULLHans de Goede2012-03-101-5/+2
| | | | | | | | | | | | | | | While git-bisecting another issue I ended up hitting and not recognizing the bug fixed by commit 7a079b452b026d6ce38f95dcc397fa64b059fffb. While fixing this (again) I noticed that (even after the fix) not all users of ChannelCbs first zero it. So this patch ensures that all users of ChannelCbs first zero it, and does the same for ClientCbs while at it. Since before this patch there were multiple zero-ing styles, some using memset and other using a zero initializer this patch also unifies all the zero-ing to use a NULL initializer for the first element. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server/inputs_channel: don't set O_ASYNC option on socketDan McGee2012-01-231-7/+2
| | | | | | | | output to send a SIGIO signal to the running program. However, we don't handle this signal anywhere in the code, so setting the option is unnecessary. Signed-off-by: Dan McGee <dpmcgee@gmail.com>
* Remove trailing blank linesDaniel P. Berrange2012-01-131-1/+0
| | | | Remove any blank lines at the end of all source files
* server: Limit the access to SpiceDataHeader of messages - only via red_channel.Yonit Halperin2012-01-121-3/+7
|
* Do not assume that SPICE is using a TCP socketDaniel P. Berrange2012-01-091-2/+4
| | | | | | | | | | If setting the TCP_NODELAY socket option fails with ENOTSUP, then don't treat this is a fatal error. SPICE is likely just running over a UNIX socket instead. * server/inputs_channel.c: Ignore TCP_NODELAY socket opt fails Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* server: set & test channel capabilities in red_channelYonit Halperin2011-11-021-1/+3
| | | | | | | The code for setting and testing channel capabilities was unnecessarily duplicated. Now it is in red_channel. RedsChannel was dropped from Reds; It was used only for holding the channels common capabilities, which are now held in RedChannel.
* server: fix function prototypesChristophe Fergeau2011-09-051-1/+1
| | | | | | | | Several functions in server/ were not specifying an argument list, ie they were declared as void foo(); When compiling with -Wstrict-prototypes, this leads to: test_playback.c:93:5: erreur: function declaration isn’t a prototype [-Werror=strict-prototypes]
* fix more inverted memset parametersHans de Goede2011-08-251-3/+3
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server: registering RedChannel in reds, instead of ChannelYonit Halperin2011-08-231-63/+52
| | | | | | | | | | | | | | | | | | | | | | | Merging the functionality of reds::channel, into RedChannel. In addition, cleanup and fix disconnection code: before this patch, red_dispatcher_disconnect_display_client could have been called from the red_worker thread (and it must be called only from the io thread). RedChannel holds only connected channel clients. RedClient holds all the channel clients that were created till it is destroyed (and then it destroys them as well). Note: snd_channel still doesn't use red_channel, however it creates dummy channel and channel clients, in order to register itself in reds. server/red_channel.c: a channel is connected if it holds at least one channel client Previously I changed RedChannel to hold only connected channel clients and RedClient, to hold all the channel clients as long as it is not destroyed. usbredir: multichannel has not been tested, it just compiles.
* server/red_channel.c: pack all channel callbacks to ChannelCbsYonit Halperin2011-08-231-10/+13
|
* server/inputs_channel: support multiple clientsAlon Levy2011-08-231-28/+29
| | | | | from server events are broadcast - leds change. The rest is client to server, so it is just passed on.
* server: Add RedClientAlon Levy2011-08-231-25/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | That means RedClient tracks a ring of channels. Right now there will be only a single client because of the disconnection mechanism - whenever a new client comes we disconnect all existing clients. But this patch adds already a ring of clients to reds.c (stored in RedServer). There is a known problem handling many connections and disconnections at the same time, trigerrable easily by the following script: export NEW_DISPLAY=:3.0 Xephyr $NEW_DISPLAY -noreset & for ((i = 0 ; i < 5; ++i)); do for ((j = 0 ; j < 10; ++j)); do DISPLAY=$NEW_DISPLAY c_win7x86_qxl_tests & done sleep 2; done I fixed a few of the problems resulting from this in the same patch. This required already introducing a few other changes: * make sure all removal of channels happens in the main thread, for that two additional dispatcher calls are added to remove a specific channel client (RED_WORKER_MESSAGE_CURSOR_DISCONNECT_CLIENT and RED_WORKER_MESSAGE_DISPLAY_DISCONNECT_CLIENT). * change some asserts in input channel. * make main channel disconnect not recursive * introduce disconnect call back to red_channel_create_parser The remaining abort is from a double free in the main channel, still can't find it (doesn't happen when running under valgrind - probably due to the slowness resulting from that), but is easy to see when running under gdb.
* server: move pipe from RedChannel to RedChannelClientAlon Levy2011-08-231-27/+9
| | | | | | | | | | | | | | | | | | | | | | | Another cleanup patch, no change to behavior (still one client, and it disconnects previous client if any). The implementation for multiple client is straightforward: the pipe remains per (channel,client) pair, so it needs to move from the RedChannel that to RedChannelClient. Implementation using a single pipe with multiple consumers (to reflect different latencies) doesn't fit well with pipe rewriting that is used by the display channel. Additionally this approach is much simpler to verify. Lastly it doesn't add considerable overhead (but see the display channel changes in a later patch for a real place to rethink). This patch is just technical, changing signatures to reflect the first argument (oop style) so red_channel becomes red_channel_client. Some places may seem odd but they should be fixed with later comits where the channels grow to support multiple clients. Sound (playback/record) channels are the only ones not touched - this is consistent with previous patches, since they have been left out of the RedChannel refactoring. That is left as future work. (note that they don't use a pipe, which was the reason for not refactoring).
* server/red_channel (all): introduce RedChannelClientAlon Levy2011-08-231-17/+22
| | | | | | | | | | | | | | | | | | | | | This commit adds a RedChannelClient that now owns the stream connection, but still doesn't own the pipe. There is only a single RCC per RC right now (and RC still means RedChannel, RedClient will be introduced later). All internal api changes are in server/red_channel.h, hence the need to update all channels. red_worker.c is affected the most because it makes use of direct access to some of RedChannel still. API changes: 1. red_channel_client_create added. rec_channel_create -> (red_channel_create, red_channel_client_create) 2. two way connection: rcc->channel, channel->rcc (later channel will hold a list, and there will be a RedClient to hold the list of channels per client) 3. seperation of channel disconnect and channel_client_disconnect TODO: usbredir added untested.
* add #include <config.h> to all source filesChristophe Fergeau2011-05-031-0/+3
| | | | | | | | When using config.h, it must be the very first include in all source files since it contains #define that may change the compilation process (eg libc structure layout changes when it's used to enable large file support on 32 bit x86 archs). This commit adds it at the beginning of all .c and .cpp files
* 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
* server/red_channel (+): remove red_channel_add_bufAlon Levy2011-03-021-1/+0
|
* server/red_channel (all): add red_channel_get_streamAlon Levy2011-03-021-3/+4
| | | | | use in config_socket, this makes the stream internal to the RedChannel implementation that will change later for multiple client support.
* server/red_channel (all): handle MIGRATE_DATA and MIGRATE_FLUSH_DATAAlon Levy2011-03-021-1/+4
| | | | | | | | | | 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-021-2/+1
| | | | | | | 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/inputs_channel: s/PIPE_ITEM_INIT/PIPE_ITEM_INPUTS_INIT/Alon Levy2011-03-021-3/+3
|
* server/red_channel (all): makes red_channel_reset_send_data privateAlon Levy2011-03-021-1/+0
| | | | ready the way for handling ack messages in RedChannel.
* server/red_channe: make hold_item take a channel argAlon Levy2011-03-021-1/+1
|
* server: rename s/peer/streamMarc-André Lureau2011-02-281-5/+5
| | | | | | | | This is stylish change again. We are talking about a RedStream object, so let's just name the variable "stream" everywhere, to avoid confusion with a non existent RedPeer object. https://bugs.freedesktop.org/show_bug.cgi?id=34795
* server: s/RedsStreamContext/RedsStreamMarc-André Lureau2011-02-271-1/+1
| | | | https://bugs.freedesktop.org/show_bug.cgi?id=34795
* server/red_channel: reflect SpiceDataHeader fields in handle_parsed_procAlon Levy2011-02-071-1/+1
|
* server/red_channel: add red_channel_pipe_add_pushAlon Levy2011-02-071-4/+4
|
* server/red_channel: add hold_item (from red_worker)Alon Levy2011-02-071-0/+5
| | | | | | | | | | | | | hold_item called on init_send_data, matching release. This is not the behavior of red_worker - we ref++ (==hold_item) when sending the item, and --refs when releasing it, instead of only holding if the send is blocked. Note 1: Naming: hold_pipe_item is the proc name, the variable is called hold_item, this is similar to release_item/release_pipe_item naming. Note 2: All channels have empty implementation, we later use this when red_worker get's RedChannelized.
* server/inputs_channel: use outgoing marshaller in red_channel/RedChannelAlon Levy2011-01-161-58/+76
|
* server/inputs: return NULL on alloc_buf request for too large messageAlon Levy2010-12-071-0/+4
|
* server/inputs_channel: better protection from channel disconnection on ↵Alon Levy2010-12-071-1/+1
| | | | keyboard modifiers callback
* server/inputs_channel: s/inputs_channel/g_inputs_channel/Alon Levy2010-12-071-17/+22
|
* server/inputs_channel: initialize inputs_channel to NULLAlon Levy2010-12-071-1/+1
|
* server: reds/inputs_channel: move some structs to inputs_channelAlon Levy2010-12-071-0/+12
|
generated by cgit (git 2.34.1) at 2024-04-30 15:34:30 +0000