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.
Add a backtrace printing function copied from xserver os/backtrace.c
that uses gstack, and if that isn't found then glibc's backtrace.
Used in ASSERT, tested on F15.
These messages allow the guest to send the audio device volume to the
client. It uses an arbitrary scale of 16bits, which works good enough
for now.
Save VolumeState in {Playback,Record}State, so that we can send the
current volume on channel connection.
Note about future improvements:
- add exact dB support
- add client to guest volume change
Updated since v2:
- bumped record and playback interface minor version to allow
conditional compilation
Updated since v1:
- sync record volume on connection too
needed for spice/common files used by the client, server & qxl driver.
in windows _inline works for both c/c++, while inline is c++ only.
compiling the client with mixed c/c++ code required this define.
Code adapter from RedPeer::ssl_verify_callback() and used by
spice-gtk.
Since v1:
- fixed Makefile.am
- added config.h include
- autoconf alloca added in patch series
- moved int escape inside for loop
- added a failed case when missing assignment
- replaced strlen () by -1
- skip spaces after comma
- c++ guards
I didn't use bool, because openSSL uses int, and it is more future
proof for error reporting.
spice_common.h provides an ASSERT macro, no need to duplicate it
in many places. For now client/debug.h keeps its own copy since
debug.h and spice_common.h have clashes on other macros which are
trickier to unify.
When using config.h, it must be the very first include in all source
files since it contains #define that may change the compilation process
(eg libc structure layout changes when it's used to enable large file
support on 32 bit x86 archs). This commit adds it at the beginning
of all .c and .cpp files
spice client and spice server shares code from
common/{gdi,gl,sw}_canvas.[ch]. However, while most of the code is
shared, the server code wants a canvas compiled with
SW_CANVAS_IMAGE_CACHE defined while the client code wants a canvas
compiled with SW_CANVAS_CACHE.
The initial autotools refactoring didn't take that into account,
this is now fixed by this commit. After this commit, the canvas
files from common/ are no longer compiled as part of the
libspice-common.la convenience library. Instead, there are "proxy"
canvas source files in client/ and server/ which #include the
appropriate C files after defining the relevant #define for the
binary that is being built.
To prevent misuse of the canvas c files and headers in common/,
SPICE_CANVAS_INTERNAL must be set when including the canvas headers
from common/ or when building the c files from common/ otherwise
the build will error out.
spice Makefile.am setup is a bit confusing, with source file
names being listed several times in different Makefile.am
(generally, once in EXTRA_DIST and another time in another
Makefile.am in _SOURCES). The client binaries are built
by client/x11/Makefile.am, which means recursing into client,
then into x11 to finally build spicec. This Makefile.am is
also referencing files from common/ and client/, which is
a bit unusual with autotools.
This patch attempts to simplify the build process to get
something more usual from an autotools point of view.
The source from common/ are compiled into a libtool convenience
library, which the server and the client links against which avoids
referencing source files from common/ when building the server and
the client. The client is built in client/Makefile.am and directly
builds files from x11/ windows/ and gui/ if needed (without
recursing in these subdirectories).
This makes the build simpler to understand, and also makes it
possible to list source files once, which avoids potential
make distcheck breakage when adding new files.
There is a regression in this patch with respect to
sw_canvas/gl_canvas/gdi_canvas. They should be built with
different preprocessor #defines resulting in different behaviour
of the canvas for the client and the server. However, this is not
currently the case, both the client and the server will use the same
code for now (which probably means one of them is broken). This will
be fixed in a subsequent commit.
make distcheck passes, but compilation on windows using the
autotools build system hasn't been tested, which means it's likely
to be broken. It shouldn't be too hard ot fix it though, just let
me know of any issues with this.
canvas_base.c tries to define PANIC, but it might already be set
if eg client/debug.h has been included before. All the other
macros in this file are guarded by #ifndef, this commit adds
the missing #ifndef to PANIC. Note that this is just a bandaid,
ideally common/ would contain a logging frameword, and these
macros would only be defined once instead of being defined in
several places.
Since some spice C++ code is using code from common/, the C
functions need to be marked as such for the C++ compiler, otherwise
we'll get linkage issues.
clang static analyzer warned that 'len' was computed but never
used in glc_vertex2d. glc_stroke_line_dash has side effects so
we have to call it, but we don't need to save its return value
since it's not used.
move all the ASSERT/PANIC/PANIC_ON/red_error/red_printf* macros
to a common file to be used with ring.h that is going to be used externally
(by spice-gtk).
This is the only unused var change I'll want to revisit eventually,
I'm submitting anyway since it doesn't change current behavior. I'm
talking about ignoring the return value from canvas creation. Adding
a print is possible but I didn't test (may be too verbose, also
preferable to be a debug print if so, and we don't have that option
in the code atm - probably an environment variable will do, or adding
some spice_server_set_logging_level api, maybe even
spice_server_set_logging_fd?)
Allow top_down flag to have any value, only ASSERT it is positive
when needs to be positive and zero otherwise. Allows older server
bug of sending 4 instead of 1 in top down flag to not affect newer
clients (previous patch fixes server).
When scaling part of an image we need to specify the source
coordinates in transformed coordinates. For large magnifications this
means we will get pretty large values.
Now, if e.g. src_x * transform is larger than 32765, then the
coordinate ends up outside the pixman 16bit image size, so the
rendering will not work.
The fix is to make the src_x/y offset part of the transformation.
This means its automatically transformed by the correct scaling, and
the coordinates passed into pixman are not (typically) over 16bit.
When scaling part of an image we need to specify the source coordinates
in transformed coordinates. For large magnifications this means
we will get pretty large values.
Now, if e.g. src_x * transform is larger than 32765, then the coordinate
ends up outside the pixman 16bit image size, so the rendering
will not work.
In order to work around this we generate a "sub-image" of the pixman
image such that the src_x/y values we have to specify are zero (or near
zero).
When scaling in pixman you give the source coordinates in transformed
space rather than in the source coordinates. This is a bit problematic
when both source and destination coordinates are at integer positions, but
the scaling factor is not an exact 16.16 fixed point value. We used
to calculate the transformed source based on the floating point
transformation, which gave the wrong answer sometimes. Now we do the
calculations based on the fixed point transform that we give pixman.
However, even with this patch I can still sometimes see issues related
to this, although they are less bad.
