summaryrefslogtreecommitdiffstats
path: root/client
Commit message (Collapse)AuthorAgeFilesLines
* Don't truncate SPICE_FOREIGN_MENU_SOCKETChristophe Fergeau2012-03-201-5/+8
| | | | | | | When we get the socket name for the foreign menu socket from an environment variable, we cannot make assumptions about its length. Currently, we are strncpying to a 50 byte buffer which is easily too small.
* Don't limit spice controller socket name to 50 charsChristophe Fergeau2012-03-201-6/+4
| | | | | | | | | | | | | | | | | | The spice controller socket name used to be hardcoded to /tmp/SpiceController-%lu.uds and generated using snprintf. A 50 bytes buffer was enough for that, but this was changed in commit 79fffbf95 because this was predictable and allowed other users on the system to sniff the browser/client communication. spicec now uses the value of the environment SPICE_XPI_SOCKET as the name of the socket to use. However, since the name that is used is no longer generated by spicec, no assumption can be made about its size. Currently, the socket is created inside the user home directory, which means that if the user name is too long, spicec will not be able to read the controller socket name. This commit directly uses the string from getenv as he name of the controller socket (on Linux) instead of limiting its size to 50 characters, which should fix this issue. This fixes rhbz #804561
* Remove unused Canvas membersChristophe Fergeau2012-03-204-8/+0
| | | | | The various Canvas have _max and _base variables which are not used, better to remove them.
* Use SPICE_FOREIGN_MENU_SOCKET if it's availableMarc-André Lureau2012-03-052-2/+8
| | | | | | | | | | | If specified, use SPICE_FOREIGN_MENU_SOCKET environment variable over snprintf(pipe_name, PIPE_NAME_MAX_LEN, PIPE_NAME, Platform::get_process_id()); since it's impossible to guess the client pid when spice-xpi launches the client as a grand-child (via script etc). This is also more aligned with the way we handle SPICE_XPI_SOCKET location.
* mingw: fix signed/unsigned comparison warningsChristophe Fergeau2012-03-043-3/+3
|
* mingw: add workaround for _ftime_s issue on mingwChristophe Fergeau2012-03-041-0/+7
| | | | | | | mingw has a _ftime_s prototype in its headers, but no corresponding symbol available at link time. Workaround this issue for now by #defining it to _ftime. This is untested on win64 where the workaround may not be needed.
* mingw: #ifdef unneeded #define in common.hChristophe Fergeau2012-03-041-0/+2
| | | | | | | | | common.h has some #define when doing win32 build to workaround a few missing functions on these systems. However, since mingw32 has some of these, this causes either warnings about redefining preprocessor symbols or wreak havoc in mingw headers trying to use these symbols. This commit wraps these symbols in an #ifndef __MINGW32__ to avoid using them on this platform.
* mingw: use uintptr_t when converting a pointer to an intChristophe Fergeau2012-03-042-2/+2
| | | | | | win64 uses 32 bit long, so we cannot use a long to hold a 64 bit pointer. Thankfully, there's a [u]intptr_t type available exactly for these uses.
* client/windows: fix SetClipboardViewer error handling rhbz#786554Arnon Gilboa2012-03-011-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.
* client X11: support volume keys when evdev is in useYonit Halperin2012-03-011-0/+6
| | | | | | | Add support for sending volume keys scancodes to the guest RHBZ #552539 Signed-off-by: Yonit Halperin <yhalperi@redhat.com>
* client: keyboard - add mapping for volume keysYonit Halperin2012-03-012-0/+6
| | | | | | | | | | Add support for sending volume keys scancodes to the guest RHBZ #552539 A good reference for mapping keymaps to scancodes can be found in spice-gtk/gtk/keymaps.csv Signed-off-by: Yonit Halperin <yhalperi@redhat.com>
* Fix compilation when smartcard support is disabledChristophe Fergeau2012-02-294-0/+8
| | | | | | The addition of smartcard control to the controller doesn't handle the case when smartcard support is disabled at compile time. When this is the case, this causes compile errors.
* controller_test: add READMEAlon Levy2012-02-281-0/+10
|
* client controller_test: reorder parameters since pid isn't needed for linux ↵Alon Levy2012-02-281-3/+3
| | | | client test
* client: handle CONTROLLER_ENABLE_SMARTCARD (rhbz 641828)Alon Levy2012-02-284-1/+11
|
* controller_test: add ENABLE_SMARTCARDAlon Levy2012-02-281-0/+4
|
* Handle Application::set_hotkeys failureChristophe Fergeau2012-02-032-17/+30
| | | | | | | | Application::set_hotkeys can throw an exception if it fails parsing the string describing the hotkeys to set. Currently this exception is uncaught which causes spicec to terminate when the controller tries to set invalid hotkeys. Fall back to using the default hotkeys when the controller sends an invalid hotkeys string.
* Don't use "hw:0,0" for recording with alsaChristophe Fergeau2012-01-311-1/+1
| | | | | | | | | We currently hardcode this device when spicec needs to record with alsa. However, this doesn't interact well with PulseAudio, which means that if something is already using the recording device, spicec won't be able to open it again. Using "default" as the device will let spicec use the PulseAudio alsa support and will avoid this issue.
* More comparison between signed and unsigned integer expressions warning fixesHans de Goede2012-01-232-3/+2
| | | | | | | | | | Turns out that more recent snapshots of gcc-4.7 emit even more of these, so the fixes which I've done before tagging the 0.10.1 release are not enough to build warning free with the latest gcc-4.7 snapshot <sigh>. This fixes this. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Fix various comparison between signed and unsigned integer expressions warningsHans de Goede2012-01-234-9/+9
| | | | | | These turn into errors because of our -Werror use, breaking the build. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Remove epoll headers from client codeDan McGee2012-01-232-2/+0
| | | | | | | There is no more usage of epoll on the client side, so no need to include these header files. Signed-off-by: Dan McGee <dpmcgee@gmail.com>
* Update .gitignore with a few more generated filesDan McGee2012-01-232-0/+2
| | | | Signed-off-by: Dan McGee <dpmcgee@gmail.com>
* client/foreign_menu: arm build fixAlon Levy2012-01-221-1/+1
|
* Remove trailing whitespace from end of linesDaniel P. Berrange2012-01-139-20/+20
|
* Remove trailing blank linesDaniel P. Berrange2012-01-13126-128/+1
| | | | Remove any blank lines at the end of all source files
* Death to all TABsDaniel P. Berrange2012-01-138-763/+763
| | | | | | Source files should all use spaces instead of tabs for indentation. Update the few files not already in compliance
* client/windows: fix several assigned but not used errorsAlon Levy2012-01-131-2/+1
|
* 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
generated by cgit (git 2.34.1) at 2024-06-11 18:18:58 +0000