summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* client: display channel migrationYonit Halperin2011-11-022-14/+153
| | | | | | | | (cherry picked from commit cad3c585444f940f60c12789f4174f2d32bec70f branch 0.8) Conflicts: client/display_channel.cpp
* client: playback/record channels: implement on_disconnectYonit Halperin2011-11-023-19/+54
| | | | (cherry picked from commit d3ed9d5e9d52ddcadcb3c8c77dd827b50071d813 branch 0.8)
* client: main channel migration: do partial cleanup when switching hostsYonit Halperin2011-11-022-0/+11
| | | | | | | Implement on_disconnect_mig_src and on_connect_mig_target in order to avoid unnecessary cleanups done in on_(disconnet|connect). In addition, do not request guest display settings changes after migration. (cherry picked from commit f91d202eb3bf631cf5e70277d1aabffec7da9393 branch 0.8)
* client: handle SPICE_MSG_MAIN_MIGRATE_ENDYonit Halperin2011-11-024-11/+187
| | | | | | | | | | | | | (1) disconnect all channels from the migration src (2) after all channels are disconnected, clean global resources (3) send SPICE_MSGC_MAIN_MIGRATE_END to migration target (4) wait for SPICE_MSG_MAIN_INIT (4) switch all channels to migration target (cherry picked from commit 510a4ff7c4f188fe6d0fb12198b8f9fdb74b9a2d branch 0.8) Conflicts: client/red_channel.h
* client: handle SpiceMsgMainMigrationBegin (semi-seamless migration)Yonit Halperin2011-11-021-3/+20
| | | | | | | | | RHBZ 725009, 738270 (cherry picked from commit 31ed2519a752b7332ed40d0d7ab02e938c0e65cb branch 0.8) Conflicts: client/red_client.cpp
* client: rewrite surfaces cacheYonit Halperin2011-11-0210-263/+101
| | | | | | | | | | | use std::map instead of a specific template (CHash). There is no need for special template. Moreover, using std::map will allow easy iteration over the surfaces. (cherry picked from commit fcb3b4ce5231218bcf949da4270bd85a2cfb3535 branch 0.8) Conflicts: client/display_channel.cpp
* server: turn spice_server_migrate_start into a valid callYonit Halperin2011-11-021-7/+1
| | | | | | We will add a qemu call to spice_server_migrate_start when migration starts. For now, it does nothing, but we may need this notification in the future. (cherry picked from commit b8213167717979e6f2fb52646e43eb458634e6a1 branch 0.8)
* server: handling semi-seamless migration in the target sideYonit Halperin2011-11-026-46/+248
| | | | | | | | | | (1) not sending anything to a migrated client till we recieve SPICE_MSGC_MIGRATE_END (2) start a new client migration (handle client_migrate_info) only after SPICE_MSGC_MIGRATE_END from the previous migration was received for this client (3) use the correct ticket Note: we assume the same channles are linked before and ater migration. i.e., SPICE_MSGC_MAIN_ATTACH_CHANNELS is not sent from the clients.
* server: move the linking of channels to a separate routineYonit Halperin2011-11-021-17/+28
|
* server: handle spice_server_migrate_endYonit Halperin2011-11-024-108/+117
| | | | | | | | | | | | | | | | If the migration has completed successfully: (1) send MSG_MAIN_MIGRATE_END to the clients that are connected to the target (2) send MSG_MAIN_SWITCH_HOST to all the other clients If the migration failed, send MSG_MAIN_MIGRATE_CANCEL to clients that are connected to the target. (cherry picked from commit 4b82580fc36228af13db4ac3c403753d6b5c40b5 branch 0.8; Was modified to support multiple clients, and the separation of main_channel from reds) Conflicts: server/reds.c
* spice.proto: add SPICE_MSG_MAIN_MIGRATE_END & SPICE_MSGC_MAIN_MIGRATE_ENDYonit Halperin2011-11-021-0/+4
| | | | (cherry picked from commit cfbd07710562e522179ae5a7085a789489a821bb branch 0.8)
* server,proto: tell the clients to connect to the migration target before ↵Yonit Halperin2011-11-027-152/+176
| | | | | | | | | | | | | | | migraton starts (1) send SPICE_MSG_MAIN_MIGRATE_BEGIN upon spice_server_migrate_connect (to all the clients that support it) (2) wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) from all the relevant clients, or a timeout, in order to complete client_migrate_info monitor command (cherry picked from commit 5560c56ef05c74da5e0e0825dc1f134019593cad branch 0.8; Was modified to support the separation of main channel from reds, and multiple clients) Conflicts: server/reds.c
* configure: spice-protocol >= 0.9.1 (semi-seamless migration protocol)Yonit Halperin2011-11-021-1/+1
| | | | | | | | (cherry picked from commit 55ccc022ec9829523ebe36fdf0ec7c593ce76c22 branch 0.8) Conflicts: configure.ac
* server: handle migration interface additionYonit Halperin2011-11-022-0/+33
| | | | | | | | (cherry picked from commit 3ac0075cdac8fa42de47a7882022795e96cb1fee branch 0.8) Conflicts: server/reds.h
* server/spice.h: semi-seamless migration interface, RHBZ #738266Yonit Halperin2011-11-023-4/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | semi-seamless migration details: migration source side --------------------- (1) spice_server_migrate_connect (*): tell client to link to the target side - send SPICE_MSG_MAIN_MIGRATE_BEGIN. This should be called upon client_migrate_info cmd. client_migrate_info is asynchronous. (2) Complete spice_server_migrate_connect only when the client has been connected to the target - wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) or a timeout. (3) spice_server_migrate_end: tell client migration it can switch to the target - send SPICE_MSG_MAIN_MIGRATE_END. (4) client cleans up all data related to the connection to the source and switches to the target. It sends SPICE_MSGC_MAIN_MIGRATE_END. migration target side --------------------- (1) the server identifies itself as a migraiton target since the client is linked with (connection_id != 0) (2) server doesn't start the channels' logic (channel->link) till it receives SPICE_MSGC_MAIN_MIGRATE_END from the client. * After migration starts, the target qemu is blocked and cannot accept new spice client connections. Thus, we trigger the connection to the target upon client_migrate_info command. (cherry picked from commit 6e56bea67c5648b0c81990171d4bc0cf1a402043 branch 0.8) Conflicts: server/spice.h
* server: set & test channel capabilities in red_channelYonit Halperin2011-11-0211-181/+226
| | | | | | | 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.
* [0.8 branch] server: add main_dispatcherAlon Levy2011-10-314-1/+159
| | | | | | | | | | | | | | | | | | | | | | | add main_dispatcher, a message passing mechanism for sending messages to the main thread. The main thread is the thread that implements SpiceCoreInterface, which is assumed to be a single thread. Similar to the async operation of red_worker, a socket pair is created and used to pass messages. The messages are a fixed size to ease parsing. A single message is defined to pass a channel_event. RHBZ: 746950 FDBZ: 41858 This patch is 0.8 branch only, for the master branch there should be a better approach to share code with red_dispatcher and ready the way for later adding more threads. cherry-pick from 0.8 80caf07e09efe14c67f89a3c01501a6a39681167 Conflicts: server/reds.c
* spice-server.pc.in: move Requires to Requires.privateLiang Guo2011-10-231-1/+1
| | | | | | | | | | When using pkg-config, Requires and Requires.private field list packages required by this package, but packages listed under Requires.private are not taken into account when a flag list is computed for dynamically linked executable. In the situation where each .pc file corresponds to a library, Requires.private shall be used exclusively to specify the dependencies between the libraries.
* server/red_worker: fix placing of ↵Yonit Halperin2011-10-181-4/+6
| | | | | | | ASSERT(red_channel_client_no_item_being_sent) (fdbz #41523) Call ASSERT(red_channel_client_no_item_being_sent) only if red_wait_outgoing_item/s did not timeout.
* client/x11: reset screen positions in XMonitor::do_restoreChristophe Fergeau2011-10-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | XMonitor::do_restore (called for example when going out of fullscreen) restore the screen resolution to its previous state, but it doesn't take care of repositioning the screen to their previous position, which is one of the advantages of using randr 1.2. Since MultyMonScreen::restore handles all of this for us, just call it to restore the monitor position/resolutions to their previous settings. Before doing any changes, MultyMonScreen::restore checks if there's something to do, so calling it once per monitor won't be an issue, the resolution/position will only be set the first time. This has the side-effect of fixing bug #693431. This bug occurs when closing the client after the client went in and out of fullscreen. MultyMonScreen::~MultyMonScreen calls MultyMonScreen::restore, which decides to change the screen positions since they were lost when going to fullscreen because XMonitor::restore didn't restore the positions. After this change, the positions will be properly restored and MultyMonScreen::restore won't be needlessly called upon client shutdown.
* client/x11: fix mode setting in MultyMonScreen::restoreChristophe Fergeau2011-10-051-7/+1
| | | | | | | | | MultyMonScreen::restore changes the X11 Screen resolution, but it doesn't use MultyMonScreen::set_size. This means MultyMonScreen::_width and MultyMonScreen::_height don't get updated to reflect the new resolution settings, which could cause issues later on. Until now this was safe since the only caller of MultyMonScreen::restore was MultyMonScreen destructor.
* client/x11: fix typos (finde => find)Christophe Fergeau2011-10-051-7/+7
|
* client: fix typo commnad=>commandChristophe Fergeau2011-09-202-3/+3
|
* client: don't crash when booting a Xinerama setupChristophe Fergeau2011-09-191-4/+6
| | | | | | | | | | | | | | | | | | In a Xinerama setup, when X starts up and creates one of the secondary screens, first a non-primary surface is created on the secondary screen, and then the primary surface for this screen is created. This causes a crash when the guest uses Xinerama and the client is attached to the VM before X starts (ie while the guest is booting). This happens because DisplayChannel::create_canvas (which is called when creating a non-primary surface) assumes a screen has already been set for the DisplayChannel while this only happens upon primary surface creation. However, it uses the screen for non important stuff, so we can test if screen() is non NULL before using it. This is what is done in other parts of this file. Fixes rhbz #732423
* replace warning with comment in glz_usr_free_imageChristophe Fergeau2011-09-191-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When running some xinerama tests, I got several glz_usr_free_image: error messages. Looking at the code, this error is reported when this function is called from a different DisplayChannelClient than the one which created the glz compressed image. When this happens, the backtrace is at glz_encoder_dictionary.c:362 0x7fff940b6670) at glz_encoder_dictionary.c:449 image_type=LZ_IMAGE_TYPE_RGB32, image_width=512, image_height=256, image_stride=2048, first_lines=0x0, num_first_lines=0, usr_image_context=0x7fff7420da40, image_head_dist=0x7fff9b2a3194) at glz_encoder_dictionary.c:570 top_down=4, lines=0x0, num_lines=0, stride=2048, io_ptr=0x7fff740ea7c0 " ZL", num_io_bytes=65536, usr_context= 0x7fff7420da40, o_enc_dict_context=0x7fff7420da60) at glz_encoder.c:255 drawable=0x7fff9b46bc08, o_comp_data=0x7fff9b2a3350) at red_worker.c:5753 0x7fff9b46bc08, can_lossy=0, o_comp_data=0x7fff9b2a3350) at red_worker.c:6211 0x7fff9b46bc08, can_lossy=0) at red_worker.c:6344 0x7fff74085c50, dpi=0x7fff7445b890, src_allowed_lossy=0) at red_worker.c:7046 0x7fff7445b890) at red_worker.c:7720 at red_worker.c:7964 at red_worker.c:8431 Since the glz dictionary is shared between all the DisplayChannelClient instances that belong to the same client, it can happen that the glz dictionary code decides to free an image from one thread while it was added from another thread (thread == DisplayChannelClient), so the error message that is printed is not an actual error. This commit removes this message and adds a comment explaining what's going on.
* fix typosChristophe Fergeau2011-09-154-41/+41
| | | | | | | applicaion => application Attache => Attach Detache => Detach _layes => _layers
* server: fix function prototypesChristophe Fergeau2011-09-0515-44/+42
| | | | | | | | 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 bug #692833Marc-André Lureau2011-09-011-1/+7
|
* add C++ guards to backtrace.hChristophe Fergeau2011-09-011-0/+6
| | | | | Without these, spice_backtrace() can't be used from the C++ client code.
* server: init all fields on SpiceMsgDisplayStreamCreateChristophe Fergeau2011-09-011-0/+2
| | | | | | | | | red_display_marshall_stream_start initializes a SpiceMsgDisplayStreamCreate structure before marshalling it and sending it on the wire. However, it never fills SpiceMsgDisplayStreamCreate::stamp which then causes a complaint from valgrind. This patch sets this value to 0, it's not used by the client so the value shouldn't matter.
* fix valgrind warning in test_display__streamChristophe Fergeau2011-09-011-1/+1
| | | | | | | | create_test_primary_surface::test_display_base.c creates a QXLDevSurfaceCreate structure and initialize it, but doesn't set the position field. Moreover, this structure has 4 bytes of padding to the end (as shown by pahole from dwarves), so initialize the whole structure to 0 before using it.
* Fixup NEWS entry for multiclientHans de Goede2011-08-251-1/+1
|
* Release 0.9.10.9.1Hans de Goede2011-08-252-2/+12
|
* fix more inverted memset parametersHans de Goede2011-08-252-6/+6
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* fix leak in do_jpeg_encodeChristophe Fergeau2011-08-251-0/+4
| | | | | | | | Issue found by the Coverity scanner. HDG: Fixup don't free RGB24_line if it was not allocated by do_jpeg_encode Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* fix memory leak in error pathChristophe Fergeau2011-08-251-1/+2
| | | | Issue found by the Coverity scanner
* fix inverted memset parametersChristophe Fergeau2011-08-251-1/+1
| | | | Issue found by the Coverity scanner.
* Rename usbredir channel code to spicevmcHans de Goede2011-08-254-65/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While discussing various things with Alon in Vancouver, it came up that having a channel which simply passes through data coming out of a qemu chardev frontend unmodified, like the usbredir channel does, can be used for a lot of other cases too. To facilitate this the usbredir channel code will be turned into a generic spicevmc channel, which is just a passthrough to the client, from the spicevmc chardev. This patch renames usbredir.c to spicevmc.c and changes the prefix of all functions / structs to match. This should make clear that the code is not usbredir specific. Some examples of why having a generic spicevmc pass through is good: 1) We could add a monitor channel, allowing access to the qemu monitor from the spice client, since the monitor is a chardev frontend we could re-use the generic spicevmc channel server code, so all that is needed to add this (server side) would be reserving a new channel id for this. 2) We could allow users to come up with new channels of their own, without requiring qemu or server modification. The idea is to allow doing something like this on the qemu startup cmdline: -chardev spicevmc,name=generic,channelid=128 To ensure these new "generic" channels cannot conflict with newly added official types, they must start at the SPICE_CHANNEL_USER_DEFINED_START value (128). These new user defined channels could then either be used with a special modified client, with client plugins (if we add support for those), or by exporting them on the client side for use by an external ap, see below. 3) We could also add support to the client to make user-defined channels end in a unix socket / pipe, allowing handling of the data by an external app, we could for example have a new spice client cmdline argument like this: --custom-channel unixsocket=/tmp/mysocket,channelid=128 This would allow for something like: $random app on guest -> virtio-serial -> spicevmc chardev -> -> spicevmc channel -> unix socket -> $random app on client 4) On hind sight this could also have been used for the smartcard stuff, with a 1 channel / reader model, rather then the current multiplexing code where we've our own multiplexing protocol wrapper over the libcacard smartcard protocol. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* usbredir: Merge UsbRedirState and UsbRedirChannelHans de Goede2011-08-251-33/+18
| | | | | | | Now that the Channel struct is gone and the RedChannel has the same lifetime as the chardev interface there is no need to have these 2 separate. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* usbredir: Fix crash caused by MC changesHans de Goede2011-08-251-0/+1
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* usbredir: Ensure that our msg_rcv_buf is not used re-entrantlyHans de Goede2011-08-251-0/+12
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* red_channel: Fix msg buf memleak on parser errorHans de Goede2011-08-251-0/+1
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* client: setting monitors resolution before resizing screens, RHBZ #728252Yonit Halperin2011-08-252-12/+33
| | | | fix for "client: fix endless recursion in rearrange_monitors, RHBZ #692976"
* server: add tester and todo for multiple client supportAlon Levy2011-08-232-0/+137
|
* server/snd_worker.c: add reference counting to SndChannelAlon Levy2011-08-231-3/+28
| | | | | | | | | | Fixes a valgrind discovered possible bug in spice-server - valgrind on test_playback saw it, didn't see it happen with qemu. The problem is that the frames buffers returned by spice_server_playback_get_buffer are part of the malloc'ed SndChannel, whose lifetime is smaller then that of SndWorker. As a result a pointer to a previously returned spice_server_playback_get_buffer could remain and be used after SndChannel has been freed because the client disconnected.
* server/reds: reds_client_disconnect: remove wrong check for ↵Alon Levy2011-08-231-9/+5
| | | | | | | | reds_main_channel_connected The "channel->disconnecting" parameter already protects against recursion. Removed fixed TODOs.
* server/reds: fix reds_main_channel_connectedAlon Levy2011-08-233-1/+7
| | | | | instead of checking just for reds->main_channel check that there is at least one client as well.
* server: add public spice_server_get_num_clientsAlon Levy2011-08-234-0/+16
|
* server/snd_worker.c: add red_channel_client_destroy_dummyAlon Levy2011-08-233-15/+23
|
* server/red_channel: release channel allocated message bufferAlon Levy2011-08-231-0/+1
| | | | | handler->cb->release_msg_buf was not being called except in the error path, causing a memory leak.
generated by cgit (git 2.34.1) at 2024-11-12 05:16:45 +0000