The primary buffer doesn't use stencil test. However, this should be
explicitely disabled, since the canvas might change stencil state, and
this will affect primary stencil buffer, making some of further update
operations clipped in unwanted ways.
Setting CHECKDIFF=1 environment variable will compare the rendering of
the selected canvas with a software canvas. This is useful for debugging
some rendering issues, however it is far from being perfect, since it's
not able to tell whether one or the other is actually faulty. It's a
strong indication though of which operations are incorrect.
Ideally, all operations should be checked, however, a few of them are
disabled by default because they fail all the time, and it looks like
pixman is not very accurate for blending/compositing (at least visually,
it seems gl has better rendering)
First, context must set it, then Draw/ReadBuffer must be set to FRONT,
and then explicit Flush is needed.
This patch is mostly for future reference, it is mostly discarded in
following patch using double-buffer.
client/Makefile.am:199: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
server/tests/Makefile.am:3: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
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.
