summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-03-14client: fix two narrowing conversion c++-11 warnings0.8Alon Levy2-4/+4
Warnings are from initializing members of type int from uint32_t. Fix is to change alt_image and red_icon height and width fields to ints. Example warning fixed: res.cpp:58:1: error: narrowing conversion of ‘_red_icon.<anonymous struct>::width’ from ‘const uint32_t {aka const unsigned int}’ to ‘int’ inside { } is ill-formed in C++11 [-Werror=narrowing] Signed-off-by: Alon Levy <alevy@redhat.com>
2012-03-01client/windows: fix SetClipboardViewer error handling rhbz#786554Arnon Gilboa1-3/+4
MSDN says the following about SetClipboardViewer(): "If an error occurs or there are no other windows in the clipboard viewer chain, the return value is NULL". Seems like the buggy case was "no other windows in the clipboard viewer chain", which explains the 3rd party clipboard manager workaround detailed in the bug description. It also seems like SetClipboardViewer() does not clear the error state on succcess. Calling SetLastError(0) before SetClipboardViewer() seems to solves this issue. Since we could not reproduce the bug on our env, the customer has verified on several of their systems that a private build resolved the issue.
2011-12-22client: RedScreen::RedScreen: fix initialization order of _menu_needs_updateUri Lublin1-1/+1
Related to a91b0b3ff712eb2a7d91a951f2af7842495357c3 (cherry picked from commit a3a3b34a46f57ce86da444532e1db292638a74cd)
2011-12-21client: foreign-menu: pass "active" param when creating a ForeignMenu (#769020)Uri Lublin3-4/+4
The default stays the same -- false. A race could prevent setting ForeignMenu::_active correctly. That happened when Application::on_app_activated was called before _foriegn_menu was created. When foriegn_menu was created its _active defaults to false, and that has not changed, until focus was taken out and back in spice-client window. This caused usbrdr to sometimes not auto-share devices, unless the user switched focus to a different application and back to spicec. The fix updates ForiegnMenu::_active upon creation. (cherry picked from commit fdcef173645e564be71f1b73d476c0716e91663d)
2011-12-21client: update menu if needed when exiting full-screen mode (#758260)Uri Lublin2-1/+7
(cherry picked from commit a91b0b3ff712eb2a7d91a951f2af7842495357c3)
2011-12-21client: menu: make RedWindow::set_menu() return an error-code (#758260)Uri Lublin3-5/+14
RedWindow::set_menu() can fail (on Windows when in fullscreen mode). For Windows spice-client, when in fullscreen mode, the system-menu is NULL. Returns 0 upon success, non-0 (currently only -1) upon failure. (cherry picked from commit 24d5852611c3d5be3ba824af64cd5a3356b82b9c) (seperator vs separator --> a small typo that got fixed)
2011-12-21client controller/foreign_menu: use memmove instead of memcpy in readersUri Lublin2-2/+2
When src/dst memory areas may overlap, it's safer to use memmove. (cherry picked from commit 5d28d1662e6e415367bb283d051e0a690a8ec2f2)
2011-11-24client: handle the redundant right ctrl windows' message send when a alt-gr ↵Gal Hammer1-0/+34
is pressed bz#709074 Hello, The second patch check to see if Windows is sending a fake VK_CONTROL message when the user pressed Alt-Gr when using a non-US keyboard layout (German, Czech, etc...). If the function is_fake_ctrl return true and key event is translated to a REDKEY_INVALID and the event is discarded. Gal. (cherry picked from commit 9ffa2e9990dc5d5ae61c227d10d5234753c08402)
2011-11-24client: handle the redundant right ctrl windows' message send when a alt-gr ↵Gal Hammer1-11/+14
is pressed bz#709074 Hello, I first updated the translate_key function. It now requires the windows message as parameter (will be used later). It also use the raw wparam and lparam parameters in order to remove the code duplication when calling the function. Gal. (cherry picked from commit 33be8633f5712062752efe75adc745130a72c4c2)
2011-11-13client: add xinerama supportArnon Gilboa3-0/+164
RHEL-6 Bugzilla: 695323 cherry-picked from qspice commit 003667ac99beeec9b330a07bc3569c59a96d4588 which fixes RHEL-5 541566 with merge of the one line qspice fix to SPICE_REQUIRES: 9f3fe4755f11044a45c4b21148466a997fcbf735 spice: fixed reference to xinerama pkg config file (Xinerama.pc=>xinerama.pc) Author: Yonit Halperin <yhalperi@redhat.com> (cherry picked from master, commit a30d96faa49bca73f9c6000c4123a8ffb996ee1b) Conflicts: client/Makefile.am
2011-10-25[0.8 branch] server: add main_dispatcherAlon Levy4-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.
2011-10-25server/tests: print pthread id on channel_eventAlon Levy2-2/+5
2011-10-23spice-server.pc.in: move Requires to Requires.privateLiang Guo1-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.
2011-09-27server/smartcard: error packet sending. RHBZ 741259Alon Levy1-2/+0
fix wrongly applied master patch. With this it is identical to the change in master commit b37182426923124470bf3701f4cff2a6bb345b8d
2011-09-26Release 0.8.30.8.3Yonit Halperin4-2/+14
2011-09-26client: support semi-seamless migration between spice servers with different ↵Yonit Halperin4-6/+40
protocols. It can't actually happen right now, since switch-host migration scheme will take place if the src/target server has protocol 1.
2011-09-26client: display channel - destroy all surfaces on disconnectYonit Halperin2-6/+13
Fix not destroying surfaces and other data (e.g., streams) upon disconnection.
2011-09-26client: display channel migrationYonit Halperin2-14/+153
2011-09-26client: playback/record channels: implement on_disconnectYonit Halperin3-19/+54
2011-09-26client: main channel migration: do partial cleanup when switching hostsYonit Halperin2-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.
2011-09-26client: handle SPICE_MSG_MAIN_MIGRATE_ENDYonit Halperin4-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
2011-09-26client: handle SpiceMsgMainMigrationBegin for 0.8.2Yonit Halperin1-3/+18
RHBZ 725009, 738270
2011-09-26client: RedPeer::HostAuthOptions::set_cert_subjectYonit Halperin3-51/+59
2011-09-26client: rewrite surfaces cacheYonit Halperin10-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.
2011-09-26server: fix not calling migrate_connect completion callbackYonit Halperin1-10/+8
When the server is a migration target and spice_server_migrate_connect is called before SPICE_MSGC_MIGRATE_END has been received, we start the mig_timer. We handle the migrate_connect only when receiving SPICE_MSGC_MIGRATE_END. If the mig_timer expires before that, we dismiss the request, and should call the migrate_connect completion callback. Since reds->mig_inprogress wasn't set appropriately, it wasn't called.
2011-09-26server: fall back to switch host scheme in case semi-seamless connection to ↵Yonit Halperin1-9/+17
target fails
2011-09-25server: turn spice_server_migrate_start into a valid callYonit Halperin1-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.
2011-09-25server: call migrate_connect_complete callback when no client is connectedYonit Halperin1-29/+43
2011-09-25server: handling semi-seamless migration in the target sideYonit Halperin1-20/+116
(1) not sending anything to the client till we recieve SPICE_MSGC_MIGRATE_END (2) start a new migration (handle client_migrate_info) only after SPICE_MSGC_MIGRATE_END from the previous migration has been received (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 client.
2011-09-25server: move the linking of channels to a separate routineYonit Halperin1-26/+41
2011-09-25server: move SPICE_MSG_MAIN_INIT sending code to a separate routineYonit Halperin1-23/+33
2011-09-25server: send SPICE_MSG_MAIN_MIGRATE_END on spice_server_migrate_endYonit Halperin1-18/+67
2011-09-25spice.proto: add SPICE_MSG_MAIN_MIGRATE_END & SPICE_MSGC_MAIN_MIGRATE_ENDYonit Halperin1-0/+4
2011-09-25server,proto: tell the client to connect to the migration target before ↵Yonit Halperin3-40/+115
migraton starts (1) send SPICE_MSG_MAIN_MIGRATE_BEGIN upon spice_server_migrate_connect (2) wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR), or a timeout, in order to complete client_migrate_info monitor command
2011-09-25configure: spice-protocol >= 0.8.2 (semi-seamless migration protocol)Yonit Halperin1-1/+1
2011-09-25server: handle migration interface additionYonit Halperin2-0/+33
2011-09-25server/spice.h: semi-seamless migration interface, RHBZ #738266Yonit Halperin3-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.
2011-09-20client: don't crash when booting a Xinerama setupChristophe Fergeau1-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
2011-09-20fix infinite loop in resolution changeMarc-André Lureau1-1/+7
After hours of investigation, I am a bit clueless.. It seems XRR is sending us spurious ScreenChangeNotify in a loop. So we keep calling init_monitors(), which creates new platform_win etc.. Although none of the clients seems to be resetting the screen (checked all XRRSet..). The fact that we create many platform_win looks like a bug to me, and indeed, it seems to help if we reuse the same platform_win over the various init_monitors() calls. Fixes rhbz #692833
2011-09-20fix 2 X11 related leaksChristophe Fergeau2-4/+8
2011-09-20channel: fix EVP_PKEY leakChristophe Fergeau1-3/+7
2011-09-20always set VDAgentDisplayConfig::depthChristophe Fergeau1-0/+1
Even if VDAgentDisplayConfig::depth will be unused if the VD_AGENT_DISPLAY_CONFIG_FLAG_SET_COLOR_DEPTH isn't set, it's better to initialize it anyway to avoid warnings from valgrind.
2011-09-20fix integer marshalling helpers on big endianChristophe Fergeau1-6/+6
They were trying to convert the destination pointer to an integer before trying to dereference it. The initial conversion was meant to be a cast to a pointer of the right size, not to an integer.
2011-09-20fix typo in big endian code pathChristophe Fergeau1-2/+2
uint63_t should be uint64_t
2011-09-20server/smartcard: fix smartcard_channel_send_errorAlon Levy1-23/+7
It was sending the wrong data, the memory right after the VCSMsgHeader which was actually not where the data was. Fixed by having the header and data (VSCError, 4 bytes of the error code) embedded in the ErrorItem pipe item.
2011-08-25client: setting monitors resolution before resizing screens, RHBZ #728252Yonit Halperin2-12/+34
fix for "client: fix endless recursion in rearrange_monitors, RHBZ #692976"
2011-08-03client/red_client: fix broken switch host migration (RHBZ 727969)Alon Levy1-0/+1
3f8d7e59dbd94b1837503f37b5065698df3ffbc7 introduced a regression, after sending one attach_channels message we never send another one. Fix by resetting on disconnect.
2011-07-31server/red_dispatcher: fix wrong resolution set for tabletAlon Levy1-4/+4
when changing resolutions due to the new async code paths the surface creation command was kept by reference, and later, when the red_worker signaled completion by calling async_complete the mouse mode was updated using the reference. This caused the wrong values to be read resulting in wrong resolutions set and a non working mouse pointer. Fix this by keeping a copy of the surface creation command instead of a reference. No bz. Found in testing.
2011-07-31client: fix 30s timeout regressionChristophe Fergeau1-2/+7
Changelog from Arnon Gilboa, patch from me: Commit eb6f55409412 caused the following regression: When client runs without the auto-conf or disable-effects options (either from CLI or controller), which is the case when using Spice from Admin Portal, the client will unecessarily wait for 30sec before connecting to a Windows guest with an agent running (this won't happen with linux guests or without an agent running). The mentioned patch assumed that on_agent_reply() of VD_AGENT_DISPLAY_CONFIG will call send_main_attach_channels() and connect. However, when auto-conf or disable-effects are not used, on_agent_reply() will ignore the reply and not call send_main_attach_channels(). Therefore, send_main_attach_channels() will only be called on agent timeout. The solution is to activate agent timer only if auto-conf or disable-effects. Otherwise, simply call send_main_attach_channels(). Fixes rhbz #726441
2011-07-27Drop unnecessary X11 and alsa requires from spice-server.pcHans de Goede1-3/+0
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-30 10:54:18 +0000