This message is not straight forward to grasp.
Not clear by the name why we need to wait other channels messages
before resetting the image cache.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@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>
Instead of using spice_malloc+memcpy use spice_memdup which is
doing the same.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
Palette images have padding at the end of each line, so their stride
can't be inferred from their width as is currently done. This causes a
wrong calculation of stride_encoded value which causes a wrong stride
adjustment.
Before commit 5603961ff "fix 16 bpp LZ image decompression", the output
stride was always computed as "stride = (n_comp_pixels / height) * 4"
that is assuming 4 bytes for pixel which was wrong for some output
however computing starting from width was wrong for palette images.
This commit was added to spice-gtk in v0.32~58, which nicely matches the
"client regression when upgrading from spice-gtk v0.31 to spice-gtk
v0.33".
This fix bug https://bugzilla.redhat.com/show_bug.cgi?id=1508847.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Tested-by: Philip J. Turmel <philip@turmel.org>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This flag will allow the client to perform some optimisations
on output and buffering processing.
Old clients will ignore this additional flag.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Most of the documentation is extracted from notes in spice-server
code and comments.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
There's no need for the canvas operations to be changed.
This allows without casts to have the operation structures
constants in the code.
This potentially allows to reduce attack surface having some
more data constant instead or read/write.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe de Dinechin <dinechin@redhat.com>
Just a style change, the variable does not help readability.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe de Dinechin <dinechin@redhat.com>
Is just used by ring_remove, no reason to have it.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe de Dinechin <dinechin@redhat.com>
Allows to test for bad performance on some systems.
For instance on ARMv6/ARMv7 which does not support by default
64 bit unaligned read/write this can be checked on Linux
using /proc/cpu/alignment file.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Instead of assuming that the system can safely do unaligned access
to memory use packed structures to allow the compiler generate
best code possible.
A packed structure tells the compiler to not leave padding inside it
and that the structure can be unaligned so any field can be unaligned
having to generate proper access code based on architecture.
For instance ARM7 can use unaligned access but not for 64 bit
numbers (currently these accesses are emulated by Linux kernel
with obvious performance consequences).
This changes the current methods from:
#ifdef WORDS_BIGENDIAN
#define read_uint32(ptr) ((uint32_t)SPICE_BYTESWAP32(*((uint32_t *)(ptr))))
#define write_uint32(ptr, val) *(uint32_t *)(ptr) = SPICE_BYTESWAP32((uint32_t)val)
#else
#define read_uint32(ptr) (*((uint32_t *)(ptr)))
#define write_uint32(ptr, val) (*((uint32_t *)(ptr))) = val
#endif
to:
#include <spice/start-packed.h>
typedef struct SPICE_ATTR_PACKED {
uint32_t v;
} uint32_unaligned_t;
#include <spice/end-packed.h>
#ifdef WORDS_BIGENDIAN
#define read_uint32(ptr) ((uint32_t)SPICE_BYTESWAP32(((uint32_unaligned_t *)(ptr))->v))
#define write_uint32(ptr, val) ((uint32_unaligned_t *)(ptr))->v = SPICE_BYTESWAP32((uint32_t)val)
#else
#define read_uint32(ptr) (((uint32_unaligned_t *)(ptr))->v)
#define write_uint32(ptr, val) (((uint32_unaligned_t *)(ptr))->v) = val
#endif
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
encodes_ones is called to encode a long sequence of 1 bits.
In some conditions (I manage to reproduce with a 85000x4 pixel
image fill with a single color) encodes_ones is called with a
"n" value >= 32.
This cause encode to be called with a "len" value of 32 which
trigger this assert:
spice_assert(len > 0 && len < 32);
causing a crash. Instead of calling encode with a constant
"len" as 32 call encode_32 which is supposed to encode
exactly 32 bit.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
In most occurrences bppmask is converted to 32 bit anyway.
In the left one a possible more bigger precision is not needed.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This field is easily accessible from Encoder structure.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
We never change its value, so we basically have 2 constants for the
same thing, DEFwmimax and wmimax. This commit removes the latter.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
We never change its value, so we basically have 2 constants for the
same thing, DEFwminext and wminext. This commit removes the latter
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
We never change 'evol' value, and this is currently causing issues with
gcc 7.1.1: quic.c is checking at compile-time that 'evol' is 1, 3 or 5.
This is a constant, so a static check should be good, but the compiler (gcc
7.1.1) is unable to know 'evol' value at compile-time. Since the removal
of spice_static_assert in favour of SPICE_VERIFY, this causes a
compile-time failure.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
pixman_image_unref() does not ignore NULL pointers, it tries to
dereference it which causes a crash. When trying to decode invalid QUIC
data, we could end up in a situation where 'surface' would still be
NULL when reaching the setjmp block.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
"log: Forbid the usage of obsolete SPICE_LOG_DOMAIN" introduced a small
regression, if G_LOG_DOMAIN is not set when glib.h is included, the
header will set it to a default value. Redefining it later in log.c is
going to cause a compile-time warning.
This commit adds the definition to SPICE_COMMON_CFLAGS so that it's
defined before any inclusion of glib.h is possible. This is similar to
what is done in spice/configure.ac.
This avoids this warning:
CC log.lo
log.c:44:0: warning: "G_LOG_DOMAIN" redefined
#define G_LOG_DOMAIN "Spice"
In file included from /usr/include/glib-2.0/glib.h:62:0,
from log.c:22:
/usr/include/glib-2.0/glib/gmessages.h:280:0: note: this is the location of the previous definition
#define G_LOG_DOMAIN ((gchar*) 0)
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Make sure format is a string and not a pointer.
This prevents usages like:
spice_debug(NULL);
This forbids computed format strings, but on the other hand, forcing
the use of string constants allows the compiler to always check
argument types against the format string. Moreover, there is no
occurrences of computed format strings in the current codebase.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
As we decided to not use multiple GLib domains, the SPICE_LOG_DOMAIN
macro is not really useful. This commit removes it.
Will be replaced by some different categorization.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The macro was misused and not doing static check.
Spice have other working static check macros to use.
The macro is used only by spice-common so removing it
does not cause issues to other depending projects.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
memmove already deal with any alignment so there's no
reason to have row byte pointer cast to uint32_t.
This also remove the confusing "dest" terminology used. The image
is aligned in place so the image bits are used for both destination
and source.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
