All the real work is being done in spice-common, so this patch is just
hooking up the virtual calls and adding the SPICE_DISPLAY_CAP_COMPOSITE
capability.
spice-common changes: STREAM_DATA_SIZED message was added in order to support
video streams with frames that their size is different from the initial size
that the stream was created with.
This patch also includes server and client adjustments to the new
SpiceMsgDisplayStreamData.
The client/common.h file defines __STDC_FORMAT_MACROS before
including inttypes.h so that the PRI* macros get defined in
C++. This is ignoring the possibility that other global
includes may have already pulled in inttypes.h
We need __STDC_FORMAT_MACROS to be defined before any header
files are included. Putting it in config.h satisfies this,
since config.h is always the first header
Methods which longjump, unconditionally raise an
exception, or call _exit() cannot return control
to the caller so should be annotated with 'noreturn'
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* m4/manywarnings.m4m, m4/warnings.m4: Import GNULIB warnings
modules
* m4/spice-compile-warnings.m4: Define SPICE_COMPILE_WARNINGS
* configure.ac: Replace compile warning check with a call to
SPICE_COMPILE_WARNINGS
* client/Makefile.am: Use WARN_CXXFLAGS instead of WARN_CFLAGS
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* client/red_channel.cpp: AbortTrigger::on_event can't return
given its current impl
* server/red_worker.c: red_worker_main can't return
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
All printf var-args style methods should be annotation with
their format. All format strings must be const strings.
* client/application.cpp, client/cmd_line_parser.cpp,
client/hot_keys.cpp: Avoid non-const format
* client/client_net_socket.cpp: Fix broken format specifier
* client/red_peer.cpp: Fix missing format specifier
* client/platform.h: Add SPICE_GNUC_PRINTF annotation to term_printf
* client/utils.h: Add SPICE_GNUC_PRINTF annotation to string_printf
* server/glz_encoder_config.h, server/red_worker.c: Add
SPICE_GNUC_PRINTF annotation to warning callbacks
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Note, there may be line-ending issues here is we are not careful. This file is a msdos formatted file.
There was some inconsistencies in those line-ending that I have normalized.
Signed-off-by: Aric Stewart <aric@codeweavers.com>
This involves:
generating .c instead of .cpp files
Not including "common.h"
Standardizing some parameters
Signed-off-by: Aric Stewart <aric@codeweavers.com>
The hotkey parser was generating a string with sprintf and data it got
from the controller socket (ie data which can have an arbitrary
length). Using sprintf there is a bad idea, replace it with snprintf.
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
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.
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
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 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.
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.
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.
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>
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.
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.
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.
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>
