| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
It's #define'd to 'inline', and only used in the GLZ encoder.
|
|
It's seeing regular releases and is API stable, so we don't need to
bundle it with spice-server
|
|
As the input line could be uint8_t*, uint16_t* or uint32_t*, changing
the default from uint8_t* to void* seems the correct choice to deal with
upcasting warnings.
Regarding chunks->data allocation, I quote Frediano explantion:
"Lines came from spice_bitmap_get_line. This function assume that bitmap
data is split among chunks each containing some lines
(always full lines). If chunk->data is allocated using malloc or similar
SHOULD (not 100% sure) be 4 bytes aligned so in our cases
(8, 16, 24 or 32 bit images) should be aligned enough.
All the casts unfortunately came from the fact we compute based on
pixel bytes to make it generic so we use uint8_t*."
and
"Looking at code looks like these chunks came from the virtual machine.
So the question is... why should the virtual machine give use some
not-pixel align data?
I would put a large comment to state that we assume VM send aligned
data, would be stupid for the VM to not align it!"
clang output:
jpeg_encoder.c:109:26: error: cast from 'uint8_t *'
(aka 'unsigned char *') to 'uint16_t *' (aka 'unsigned short *')
increases required alignment from 1 to 2 [-Werror,-Wcast-align]
uint16_t *src_line = (uint16_t *)line;
^~~~~~~~~~~~~~~~
jpeg_encoder.c:144:26: error: cast from 'uint8_t *'
(aka 'unsigned char *') to 'uint32_t *' (aka 'unsigned int *')
increases required alignment from 1 to 4 [-Werror,-Wcast-align]
uint32_t *src_line = (uint32_t *)line;
^~~~~~~~~~~~~~~~
mjpeg_encoder.c:260:23: error: cast from 'uint8_t *'
(aka 'unsigned char *') to 'uint16_t *' (aka 'unsigned short *')
increases required alignment from 1 to 2 [-Werror,-Wcast-align]
uint16_t pixel = *(uint16_t *)src;
^~~~~~~~~~~~~~~
|
|
Instead of using uint8_t* which can cause several warnings on casting as
the example below:
./glz_encode_tmpl.c:321:29: error: cast from 'uint8_t *'
(aka 'unsigned char *') to 'rgb16_pixel_t *' (aka 'unsigned short *')
increases required alignment from 1 to 2 [-Werror,-Wcast-align]
ref_limit = (PIXEL *)(seg->lines_end);
^~~~~~~~~~~~~~~~~~~~~~~~~
|
|
spice-protocol has a new define to create the magic constants, let's use
that.
|
|
SpiceBitmap's stride is uint32_t.
from clang:
red_parse_qxl.c:452:41: error: taking the absolute value of unsigned
type 'uint32_t' (aka 'unsigned int') has no effect
bitmap_size = red->u.bitmap.y * abs(red->u.bitmap.stride);
^
|
|
This fixes a test_display_no_ssl segfault on client disconnect when
the keyboard was never initialized.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is the place that needs the complete type definition. If it is
defined in reds.h, it can create circular references.
|
|
It doesn't make much sense to have static function declarations in a
header, even a private header. So move them down into the source file.
|
|
|
|
|
|
|
|
|
|
There is a red_init() methods, we can group all the red_init_*() calls
in it rather than calling red_init() followed by all these calls in our
main function.
|
|
This fixes the build on RHEL-6
|
|
This has been renamed to SpiceImageCompression in order to avoid clashes
with older spice-server in the SPICE_IMAGE_COMPRESS_ namespace. This
commit is a straight rename of SpiceImageCompress to
SpiceImageCompression and SPICE_IMAGE_COMPRESS_ to
SPICE_IMAGE_COMPRESSION_
|
|
This prevents a compile error on Debian Jessie, from git, such as this:
/usr/bin/ld: test_playback.o: undefined reference to symbol 'sin@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line
This is fairly subtle, and Debian specific. It only happens when you use
autoreconf to generate a new libtool script. Debian patches that script
to require an explicit setting to link with all dependent libraries.
It should be harmless on other distros, and it does save us Debian guys some
hassle.
|
|
new one
If a previous Qemu executable is not able to delete the statistic file
on the next creation with same name (statitics file are based on pid
numbers so if pid get reused for another Qemu process you get the same
name) it fails as you can't open a file with 0444 permissions (these
are the permission used to create these files).
This patch assure there are no stale file trying to remove it before the
creation of the new one. As file is based on pid and name used for spice
you are not deleting another file.
Fixes: rhbz#1177326
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
|
|
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
|
|
NET_TEST_WARMUP_BYTES is 0 so the warmup ping is the same as the one we
use to measure the latency. Even if it was not, the actual latency would
be the MIN() of both anyway so we might as well use both roundtrip times
to ward off latency jitter a bit.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
|
|
error message.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
|
|
red_marshall_image() allows to use other than QUIC compression only
when auto_lz or auto_glz image compression is set. Other images don't
have the problem because they are compressed using red_compress_image()
|
|
|
|
|
|
It is redundant with the corresponding callbacks.
|
|
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
|
|
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
|
|
Locking the individual calls that access the pixmap cache in fill_bits is
not adequately thread safe. Often a windows guest with multiple monitors
will be sending the same image via different threads. Both threads can
be in fill_bits at the same time making changes to the cache for the same
image. This can result in images being deleted before all the client
channels are finished with them or with the same image being send multiple
times. Here's what can happen with out the lock in fill_bits
On the server in red_worker.c:fill_bits
Thread 1 calls pixmap_cache_hit for Image A and finds it isn't in cache
Thread 2 calls pixmap_cache_hit for Image A and finds it isn't in cache
Thread 1 adds Image 1 to pixmap_cache (1x)
Thread 2 adds Image 1 to pixmap_cache (2x)
On the client
Channel 1 adds Image A to image_cache (1x)
Channel 2 replaces Image A in image_cache (1x)
On server
Thread 1 sends Image A rendering commands
Thread N removes Image A from pixmap_cache (image remains - 1x)
Thread 2 sends Image A rendering commands
On client
Channe1 renders from Image A
Channel N removes Image a from image_cache (image is completely removed)
Channel2 render command hangs waiting for Image A
|
|
spice-server will attempt to limit number of monitors.
Guest machine can send monitor list it accepts. Limiting the number sent
by guest will limit the number of monitors client will try to enable.
The guest usually see client monitors enabled and start using it so
not seeing client monitor won't try to enable more monitor.
In this case the additional monitor guest can support will always be
seen as heads with no attached monitors.
This allows limiting monitors number without changing guest drivers.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
|
|
AC_CONFIG_MACRO_DIRS is not available with older automake versions,
which causes autogen.sh failures on RHEL6. m4_include() can be used
instead.
|
|
The checks would lead the reader to think these functions can be called
when bit rate control is off when in fact they are only called when it
is active.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
|
|
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
|
|
This will allow to share this detection code with spice-gtk.
|
|
This factorizes a bit of configure.ac m4 code.
|
|
Besides the code factorization, this will allow smartcard support to be
automatically enabled if libcacard is present and --disable-smartcard is
not used.
|
|
With a TCP socket, the backlog doesn't seem to matter much,
perhaps because of latency or underlying protocol behaviour. However,
on UNIX socket, it is fairly easy to reach the backlog limit and the
client will get an EAGAIN error (but not ECONNREFUSED as stated in
listen(7)) that is not easy to deal with: attempting to reconnect in a
loop might busy-loop forever as there are no guarantee the server will
accept new connections, so it will be inherently racy.
Typically, Spice server can easily have up to 15 concurrent incoming
connections that are established during initialization of the session.
To improve the situation, raise the backlog limit to the default maximum
system value, which is 128 on Linux.
|
|
Don't allow setting a too long password.
|
|
Do not just check and give warning before crashing the program
accessing a NULL pointer but use spice_malloc which exits with a
proper message.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
|
|
There is already a enumeration in a public header that defines the
different streaming options, so there's no need to duplicate that
enumeration internally. Just use the public enum values.
|
|
|
|
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
|
|
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
|
|
|
|
|
