summaryrefslogtreecommitdiffstats
path: root/client
Commit message (Collapse)AuthorAgeFilesLines
...
* client/windows: arraysize(inf.bmiColors) == 1 in mingw32Alon Levy2012-01-132-0/+6
|
* client/windows: fix typo, make error messages uniqueAlon Levy2012-01-131-2/+2
|
* client/windows/main: mingw32 provides PACKAGE_VERSIONAlon Levy2012-01-131-0/+8
|
* client/common: mingw32: workaround HAVE_STDLIB_H redefined in jconfig.hAlon Levy2012-01-131-0/+3
|
* client: mingw32 build needs the jpeg_boolean defineAlon Levy2012-01-133-3/+3
|
* client/common.h: mingw32 fixAlon Levy2012-01-131-2/+2
| | | | | | define PACKAGE_VERSION only ifndef __GNUC__ Since it is defined by autoconf and so it kinda comes with using the GNU compilers.
* client/Makefile.am: mingw32 fixesAlon Levy2012-01-131-1/+14
| | | | | | * build resource file with windres * include client/windows and not client/x11 * use CXIMAGE_CFLAGS (it's already set to -DDISABLE_CXIMAGE correctly)
* client: log command line (rhbz 767581)Alon Levy2012-01-131-0/+7
|
* client-x11: Fix building with gcc-4.7Hans de Goede2012-01-132-4/+4
| | | | | | | | | | Without this change gcc says: x11/res.cpp:31:1: error: narrowing conversion of ‘(((unsigned int)_alt_image.<anonymous struct>::width) * 4u)’ from ‘unsigned int’ to ‘int’ inside { } is ill-formed in C++11 [-Werror=narrowing] x11/res.cpp:61: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] x11/res.cpp:61:1: error: narrowing conversion of ‘_red_icon.<anonymous struct>::height’ from ‘const uint32_t {aka const unsigned int}’ to ‘int’ inside { } is ill-formed in C++11 [-Werror=narrowing] cc1plus: all warnings being treated as errors Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* client: screen: fix typo _forec_update_timerUri Lublin2011-12-222-6/+6
| | | | sed -i 's/_forec_update_timer/_force_update_timer/' screen.cpp screen.h
* client: RedScreen::RedScreen: fix initialization order of _menu_needs_updateUri Lublin2011-12-221-1/+1
| | | | Related to a91b0b3ff712eb2a7d91a951f2af7842495357c3
* client: foreign-menu: pass "active" param when creating a ForeignMenu (#769020)Uri Lublin2011-12-203-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.
* client: update menu if needed when exiting full-screen mode (#758260)Uri Lublin2011-12-202-1/+7
|
* client: menu: make RedWindow::set_menu() return an error-code (#758260)Uri Lublin2011-12-203-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.
* client controller/foreign_menu: use memmove instead of memcpy in readersUri Lublin2011-12-202-2/+2
| | | | When src/dst memory areas may overlap, it's safer to use memmove.
* build: remove unused variableMarc-André Lureau2011-12-151-1/+0
|
* spelling: s/cupture/captureMarc-André Lureau2011-12-144-4/+4
|
* client: handle the redundant right ctrl windows' message send when a alt-gr ↵Gal Hammer2011-11-241-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.
* client: handle the redundant right ctrl windows' message send when a alt-gr ↵Gal Hammer2011-11-241-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.
* client: add xinerama supportArnon Gilboa2011-11-142-0/+149
| | | | | | | | | | | | | | 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>
* client: support semi-seamless migration between spice servers with different ↵Yonit Halperin2011-11-024-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. (cherry picked from commit 4b2bf4d88c253502003aa5e4b93a045742eec9b4 branch 0.8)
* client: display channel - destroy all surfaces on disconnectYonit Halperin2011-11-022-6/+13
| | | | | Fix not destroying surfaces and other data (e.g., streams) upon disconnection. (cherry picked from commit 010b22cd771b7e81363b4b6521e4265b093fcd25 branch 0.8)
* 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
* 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
* fix typosChristophe Fergeau2011-09-154-41/+41
| | | | | | | applicaion => application Attache => Attach Detache => Detach _layes => _layers
* fix bug #692833Marc-André Lureau2011-09-011-1/+7
|
* 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"
* use Xkb to get keyboard modifier maskChristophe Fergeau2011-08-171-23/+2
| | | | | | | | | | | | | | To be able to enable/disable keyboard leds on X11, we need to query the X server for which mask correspond to which led (NumLock, CapsLock). So far this was done using XKeysymToKeycode and iterating over X modifier mapping. Xkb provides XkbKeysymToModifiers for this purpose, and since we're using Xkb anyway, it makes more sense to use it. At some point, on my Fedora 15 box, XKeysymToKeycode was returning NoSymbol for CapsLock and NumLock leading to spicec not being able to change the keyboard leds when qemu tells it to. However, I couldn't reproduce this when I tried again :-/
* fix harmless typo in InputsChannel::handle_modifiersChristophe Fergeau2011-08-171-1/+1
| | | | | | | | | | | | | | InputsChannel::handle_modifiers converts _modifiers which is a bitflag of SPICE_KEYBOARD_MODIFIER_FLAGS_* to a Platform::*_MODIFIER bitflag, which is what Platform::set_keyboard_lock_modifiers expects. However, it's called with _modifiers, and the bitflag that this function computes is never used. Pass the computed bitflag to ::set_keyboard_lock_modifiers since _modifiers format is meaningless for ::set_keyboard_lock_modifiers. This bug was harmless because the two different set of modifier flags actually use the same values, so _modifiers and modifiers could be used interchangeably. However it's more future-proof to use the right format here.
* fix 2 X11 related leaksChristophe Fergeau2011-08-152-4/+8
|
* channel: fix EVP_PKEY leakChristophe Fergeau2011-08-151-3/+7
|
* always set VDAgentDisplayConfig::depthChristophe Fergeau2011-08-151-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.
* client/red_client: fix broken switch host migration (RHBZ 727969)Alon Levy2011-08-031-0/+1
| | | | | | 3f8d7e59dbd94b1837503f37b5065698df3ffbc7 introduced a regression, after sending one attach_channels message we never send another one. Fix by resetting on disconnect.
* Fix typo: treshold -> thresholdLiang Guo2011-08-021-1/+1
|
* Fix typo: seperator -> separatorLiang Guo2011-08-023-24/+24
|
* client: fix 30s timeout regressionChristophe Fergeau2011-07-311-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
* fix make distcheckChristophe Fergeau2011-07-221-1/+1
|
* client: don't die if initial agent timeout triggersChristophe Fergeau2011-07-222-2/+10
| | | | | | | | | | When the client connects to a spice VM, if an agent is detected, there will be a few messages exchanged to exchange capabilities, display resolutions, ... This exchange has a timeout in case something goes wrong. However, when it fires, the client dies. This commit changes this and lets the client connects to the guest when the timeout happens. rhbz #673973
* client: only send one SPICE_MSGC_MAIN_ATTACH_CHANNELS messagesChristophe Fergeau2011-07-222-8/+16
| | | | | | | | | | | | | | 492f7a9b fixed unwanted timeouts during initial client startup, but it also caused a bad regression when connecting to RHEL6+agent guests: the SPICE_MSGS_MAIN_ATTACH_CHANNELS message was sent multiple times, once in RedClient::handle_init, then once again in RedClient::on_agent_announce_capabilities (which can even be triggered multiple times). Sending this message multiple times is a big NO and causes the server to close the client connection, and the client to die. Add a _msg_attach_message_sent boolean to make sure we only send this message once. rhbz #712938
* client: split overlong option descriptionsChristophe Fergeau2011-07-221-2/+5
|
* client: fix endless recursion in rearrange_monitors, RHBZ #692976Yonit Halperin2011-07-214-50/+55
| | | | | | | | | | The endless recursion happens due to Application::prepare_monitors calling RedScreen::resize calling Application::rearrange_monitors calling Application::prepare_monitors I changed RedScreen::resize not to call rearrange_monitors. Instead, the monitor should be configured correctly from Application, before calling resize. In addition, I made some cleanups to allow reusing rearrange_monitors code.
generated by cgit (git 2.34.1) at 2024-05-03 19:12:58 +0000