region.c contained code to test the module.
Separate test code into a proper test.
Test is copied verbatim from the original code.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
LibreSSL 2.7 defines ASN1_STRING_get0_data, like OpenSSL 1.1.
This fixes https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229044.
Original patch from Piotr Kubaj.
Reported-by: Jack L. <xxjack12xx@gmail.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
LibreSSL 2.7 does not define ASN1_STRING_get0_data, like OpenSSL 1.1.
This fixes https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229044.
Original patch from Piotr Kubaj.
Reported-by: Jack L. <xxjack12xx@gmail.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The DUMP_JPEG compile time flag is used to dump all jpeg images
to files.
The code was saving garbage instead of proper data.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Reported-by: 谢 昆明 <KunMing.Xie@hotmail.com>
Tested-by: 谢 昆明 <KunMing.Xie@hotmail.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The error functions are supposed to not return. Using the attribute
documents that in the interface, and is better for the compiler
because most noreturn-related optimizations and spurious warning
eliminations happen at the call site.
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Calling g_log_set_handler() is problematic as this means applications
using spice-server won't be able to use g_log_set_default_handler to
manage spice logging output themselves. Since this call is only needed
for backwards compatibility (so that calling g_log together with
SPICE_DEBUG_LEVEL set has the expected behaviour), we can install it
only when SPICE_DEBUG_LEVEL is set.
Then we should deprecate SPICE_DEBUG_LEVEL once and for all.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Different processors has specific instructions to count leading
zero bits. This includes: x86. x64, arm, ppc.
For portability reason the behaviour of __builtin_clz is not
defined if the value is zero so test for it.
Currently the function is not called with the value or 0.
This increase performance decoding of about 4-5% on a x64 machine
(code size decreases a little too, but about 0.1%).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
These sources are only used by the client, so they do not belong in
libspice_common_la_SOURCES.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Nothing uses it since the GL backend was removed in 384698a
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The image is going to network and network protocol is little endian
so the numbers has to be little endian. Note that this is already done
during decoding.
Tested on a ppc64 machine.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
In a comparison with current autotools build system, meson/ninja
provides a huge improvement in build speed, while keeping the same
functionalities currently available and being considered more user
friendly.
The new system coexists within the same repository with the current one,
so we can do more extensive testing of its functionality before deciding
if the old system can be removed, or for some reason, has to stay for
good.
- Meson: https://mesonbuild.com
This is the equivalent of autogen/configure step in autotools. It
generates the files that will be used by ninja to actually build the
source code.
The project has received lots of traction recently, with many GNOME
projects willing to move to this new build system. The following wiki
page has more details of the status of the many projects being ported:
https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
Meson has a python-like syntax, easy to read, and the documentation
on the project is very complete, with a dedicated page on how to port
from autotools, explaining how most common use cases can be
implemented using meson.
http://mesonbuild.com/Porting-from-autotools.html
Other important sources of information:
http://mesonbuild.com/howtox.htmlhttp://mesonbuild.com/Syntax.htmlhttp://mesonbuild.com/Reference-manual.html
- Ninja: https://ninja-build.org
Ninja is the equivalent of make in an autotools setup, which actually
builds the source code. It has being used by large and complex
projects such as Google Chrome, Android and LLVM. There is not much to
say about ninja (other than it is much faster than make) because we
won't interact directly with it as much, as meson does the middle man
job here. The reasoning for creating ninja in the first place is
explained on the following post:
http://neugierig.org/software/chromium/notes/2011/02/ninja.html
Also its manual provides more in-depth information about the design
principles:
https://ninja-build.org/manual.html
- Basic workflow:
Meson package is available for most if not all distros, so, taking
Fedora as an example, we only need to run:
# dnf -y install meson ninja-build.
With Meson, building in-tree is not possible at all, so we need to
pass a directory as argument to meson where we want the build to be
done. This has the advantage of creating builds with different options
under the same parent directory, e.g.:
$ meson ./build --prefix=/usr
$ meson ./build-extra -Dextra-checks=true -Dalignment-checks=true
After configuration is done, we call ninja to actually do the build.
$ ninja -C ./build
$ ninja -C ./build install
Ninja defaults to parallel builds, and this can be changed with the -j
flag.
$ ninja -j 10 -C ./build
- Hacking:
* meson.build: Mandatory for the project root and usually found under
each directory you want something to be built.
* meson_options.txt: Options that can interfere with the result of the
build.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Some assert in the code are doing some paranoid test and in code
paths quite hot.
The encoding time is reduced by 30-50% while the decoding time
is reduced by a 20-30%.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
The quic code goes through a function pointer in two places in order to
try to prevent the compiler from inlining code.
Doing performance measurements this trick does not work anymore
and just make code less readable.
This patch and message was based on a previous work of
Christophe Fergeau.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
With last changes are just used once and are straight forward.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: jonathon Jongsma <jjongsma@redhat.com>
Do not extract all components and compare one by one, can be easily
compared together.
Performance measurements on a set of 16 bit images shown an improve of
about 10%.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This avoids the need for a local variable with the right name (which
was decorrelate_drow in some cases in quic_tmpl.c...)
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
'correlation_row' is always set to channel->colleration_row, and we
already pass 'channel' as an argument.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The naming is odd as this is just an alias for channel->correlate_row.
This will also help in subsequent commits to make things more
consistent with quic_rgb_tmpl.c
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Most functions in quic_tmpl.c/quic_rgb_tmpl.c have only superficial
differences. One of them is using channel->state or encoder->rgb_state.
This commit adds a local CommonState *state in all template methods
which will be used instead of channel->state or encoder->rgb_state.
This makes it easier to spot the common code between the 2 template
files...
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
We don't need 2 different implementations when the only difference is
the CommonState which is being used.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It's always set, no need to have conditional compilation based on it.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It's always set, no need to have conditional compilation based on it.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It's always set, no need to have conditional compilation based on it.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It's hardcoded at compile-time, and I don't think it was changed in
years...
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It's hardcoded at compile-time, and I don't think it was changed in
years...
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This is the only function starting with an underscore, looks
out of style.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Building with gcc 8.0.1 from Fedora 28 gives the following error:
FAILED: common/common@@spice-common@sta/marshaller.c.o
../common/marshaller.c: In function 'spice_marshaller_reserve_space':
../common/marshaller.c:311:27: error: cast between incompatible function types from 'void (*)(void *)' to 'void (*)(uint8_t *, void *)' {aka 'void (*)(unsigned char *, void *)'} [-Werror=cast-function-type]
item->free_data = (spice_marshaller_item_free_func)free;
^
cc1: all warnings being treated as errors
Which can be easily fixed by creating a new function with the correct
signature and calling free() from it.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This hack is now made obsolete by the previous commit. We can safely
remove those defines and the code now builds fine for both spice server
and spice-gtk.
commit df4ec5c318
Author: Frediano Ziglio <fziglio@redhat.com>
Date: Fri May 11 16:59:46 2018 +0100
Fix generation of Smartcard channel
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The macro for both depth is the same, reuse the definition.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
When compiling spice-common with meson/ninja under "release" mode, I get
several compiler warnings about possibly-uninitialized members. For
example:
../subprojects/spice-common/common/lines.c: In function ‘miLineArc’:
../subprojects/spice-common/common/lines.c:2167:17: error: ‘edge2.dx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
edge->e += edge->dx; \
^~
../subprojects/spice-common/common/lines.c:2426:24: note: ‘edge2.dx’ was declared here
PolyEdgeRec edge1, edge2;
^~~~~
Initializing these structures to zero silences the warnings.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Note that the ID limitation always existed but now we have the
limitation in the protocol itself with SPICE_MAX_NUM_STREAMS
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Allow to enable code to do additional or expensive checks.
The option should be used by higher level libraries.
By default the option is disabled.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
This is reproducible using desktop icons on Windows XP.
These drawing are sent for the icons on the desktop.
To get an extends.x1 >= 32 you have to move an icon out of the
screen on the left side. Set the icon size to 72 as the icon has
to be out of the screen quite a lot.
Disable the grid alignment on the desktop and move an icon out of
the screen. Select and unselect the icon.
Using "/ 32" the icon will have a white background instead of a
transparent one.
Using a "/ 8" the icon is rendered correctly.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe de Dinechin <cdupontd@redhat.com>
Due to different warning setting some GCC reports:
In file included from ../spice-common/common/sw_canvas.c:27:0,
from client_sw_canvas.c:20:
../spice-common/common/canvas_base.c: In function ‘canvas_get_lz’:
../spice-common/common/canvas_base.c:768:13: error: ‘palette’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
free(palette);
^~~~~~~~~~~~~
../spice-common/common/canvas_base.c:764:9: error: variable ‘free_palette’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
int free_palette = FALSE;
^~~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Snir Sheriber <ssheribe@redhat.com>
Some FreeBSD configurations can use LibreSSL instead of OpenSSL.
The two libraries are really similar but need some minimal adjustment.
Signed-off-by: Paweł Pękala <pawelbsd@gmail.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
They are now just the same function with same parameters,
just one calls the other.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
There's no reason to use a DIB section if we are going to use just the
memory in it assigned to a pixman surface, use normal path and memory.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The field is only assigned but never used.
This was used in the GDI canvas which has now been removed.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
longjmp can happen in different places, even after the palette
is allocated so we need to free it if it got allocated.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
