| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This commit updates spice-common to latest git master.
Since the argument to the SPICE_CHECK_xxx macros is now unused, it's
cleaner to remove it.
Christophe Fergeau (3):
Add marshaller test case
build-sys: Use ${PKG_CONFIG} rather than pkg-config
build-sys: Rework SPICE_CHECK_* m4 macros
Frediano Ziglio (1):
common: Fix typo in comment
Javier Celaya (1):
Fix linearization of several marshallers with one item
|
|
This isn't terribly useful for general debugging and makes the log
pretty noisy when transferring large files.
|
|
In certain circumstances we were printing an error message even though
the file transfer had completed successfully. It didn't cause any
problems, but it pointed out an issue in the handling of outgoing agent
messages.
The described behavior was generally only encountered when there were multiple
files being transferred at once, and most often when one or two files were
significantly smaller than another file being transferred. For example, two
20kB files and another 3MB file. The failure mechanism is basically as follows:
For each file transfer, we read a chunk for the file and then we queue a series
of messages to the guest and wait for them to be flushed before continuing to
read a new chunk of the file. (Since the maximum agent message size is 2kB, each
64kB chunk of file being read can generate up to 32 messages at a time). The
file transfer task remains in "pending" state until the flush operation is
complete. Since all agent messages go into a single channel-wide queue, waiting
for the messages to be flushed meant waiting for *all* outgoing messages to be
flushed, including those that were queued after we called flush_async().
Since agent messages can only be sent if the client has enough agent tokens, it
can take a little while for all queued messages to be sent. This means that
even if a file transfer task has sent out all of its data to the guest, it can
be kept in "pending" state for some time if other file transfer tasks or other
agent messages are added to the queue. In this situation, The guest might
notice that it has received all of the data for a file transfer task and send a
XFER_STATUS_SUCCESS message while we're still in "pending" state.
This patch changes to code so that flush_async() only waits for the
currently-queued messages to be sent. This means that it is not affected by any
new messages that get added to the outgoing queue after we've called
flush_async(). This means that the task will exit "pending" state immediately
after sending out our last data packet.
Fixes: rhbz#1265562
|
|
In order to avoid reference cycles, you're supposed to release
references in dispose, especially to those objects that can hold
references to yourself. This probably wasn't causing any leaks, since
the file transfer tasks generally are not alive when the main channel is
destroyed, but it's more proper.
|
|
In the case where a file cannot be opened for reading, we were not
emitting a 'finished' signal to communicate the error to the client.
I was intending to further fix this issue by 'rejecting' the drop (in
SpiceDisplay) when the URI list contains invalid files (e.g.
directories). This would prevent a 'new-file-transfer' signal from even
being emitted for these invalid files. But this turns out to be not very
useful since there's no real feedback given to the user to indicate why
the drop failed. So it's probably better for client applications to get
the 'new-file-transfer' and 'finished' signals so that they can present
the error to the user to explain why the attempted transfer did not
work.
|
|
Otherwise it will be leaked. There is no cache_ref function, or helper
increasing a refcount/taking a reference so cache_unref really is a
cache_free method.
This fixes:
==27687== 64 bytes in 4 blocks are definitely lost in loss record 250 of 435
==27687== at 0x4C28C50: malloc (vg_replace_malloc.c:299)
==27687== by 0xA6AF058: g_malloc (gmem.c:94)
==27687== by 0xA6C5982: g_slice_alloc (gslice.c:1007)
==27687== by 0x40F112: cache_new (spice-channel-cache.h:54)
==27687== by 0x40F112: cache_image_new (spice-channel-cache.h:64)
==27687== by 0x40F112: spice_session_init (spice-session.c:294)
==27687== by 0xA239B4A: g_type_create_instance (gtype.c:1870)
==27687== by 0xA21C31A: g_object_new_internal (gobject.c:1779)
==27687== by 0xA21DB10: g_object_newv (gobject.c:1926)
==27687== by 0xA21E3FB: g_object_new (gobject.c:1619)
==27687== by 0x40FF4D: spice_session_new (spice-session.c:1479)
==27687== by 0x40E678: test_session_uri (session.c:35)
==27687== by 0xA6CE47A: test_case_run (gtestutils.c:2158)
==27687== by 0xA6CE47A: g_test_run_suite_internal (gtestutils.c:2241)
==27687== by 0xA6CE642: g_test_run_suite_internal (gtestutils.c:2253)
|
|
display_cache is no longer refcounted since commit c9d4773, but this is
not an issue as even before, the fact that it was refcounted was not
used as there was no corresponding cache_ref() call (and
g_hash_table_ref() was not called directly either).
As the next commit will free memory from cache_unref() rather than just
releasing a reference, it's better to make it obvious that this method
is a _free() method rather than an _unref() one.
|
|
There were several shortcomings to the existing file transfer API,
particularly in terms of monitoring ongoing file transfers. The major
issue is that spice_main_file_copy_async() allows you to pass an array
of files, but the progress callback does not provide a way to
identify which file the callback is associated with. This makes it
nearly impossible for an application to monitor file transfers.
In addition, the SpiceDisplay widget automatically handles drag-and-drop
actions on the widget, and initiates file transfers without allowing the
application to specify a progress callback. So there's no way for an app
to monitor file transfers that are initiated via drag and drop.
http://lists.freedesktop.org/archives/spice-devel/2015-September/021931.html
has a more detailed explanation of the issues.
This change doesn't break the existing API, but adds some new API that
will allow an application to monitor file transfer progress, even for
transfers that are initiated within spice-gtk itself.
- A new public SpiceFileTransferTask object is added.
- The SpiceMainChannel object gains a "new-file-transfer" signal that is
emitted whenever a new file transfer is initiated. The
SpiceFileTransferTask object is passed to the signal handler.
- The application can retain this object and monitor its 'progress'
property to be notified when the progress of the file transfer
changes. The SpiceFileTransferTask::finished signal indicates when the
given file transfer has completed. The application can also cancel the
file transfer by calling the _cancel() method.
The 'spicy' test application has been updated to use this new API and
display a simple dialog showing the progress of individual files.
|
|
spice_main_file_copy_async() allows you to pass a NULL-terminated array
of files to transfer to the guest. It also allows you to pass a
progress_callback function to monitor the progress of the transfer, but
this progress callback is called separately for each file that is
transferred, and there are no parameters that allow the caller to
determine which file a given callback corresponds to. This makes it very
difficult to monitor the progress.
To make this more usable, I've changed it so that the progress callback
doesn't simply report the number of bytes read and total size of the
current file. Instead, we add up the status of all current transfers and
report that value to the callback.
|
|
Only the local declarations should be declared extern "C", otherwise it
can result in unexpected errors such as this (encountered while re-ordering
some include statements for a different patch):
CC channel-inputs.lo
In file included from /usr/include/glib-2.0/glib/gmacros.h:38:0,
from /usr/lib64/glib-2.0/include/glibconfig.h:9,
from /usr/include/glib-2.0/glib/gtypes.h:32,
from /usr/include/glib-2.0/glib/galloca.h:32,
from /usr/include/glib-2.0/glib.h:30,
from /usr/include/glib-2.0/gobject/gbinding.h:28,
from /usr/include/glib-2.0/glib-object.h:23,
from /usr/include/glib-2.0/gio/gioenums.h:28,
from /usr/include/glib-2.0/gio/giotypes.h:28,
from /usr/include/glib-2.0/gio/gio.h:26,
from ../../src/spice-channel.h:27,
from ../../src/channel-inputs.h:25,
from ../../src/channel-inputs.c:20:
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stddef.h:147:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'typedef'
typedef __PTRDIFF_TYPE__ ptrdiff_t;
^
|
|
This header is the single include needed for all gtk-related
functionality, similar to spice-client.h. Generate a compiler warning if
a different header is included.
|
|
Generate a compiler warning if an application attempts to include a
different header.
|
|
'sources' should be a NULL-terminated array, but the parameter
documentation treats it as if it is a single file object.
|
|
|
|
Since these messages are only used for terminal debug output, let's not
waste time translating them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Some translatable strings were added in commit 8c37a340.
|
|
This will allow Windows guests to determine if the client supports a
monitors_config message from a multi-monitor guest that is not
multi-headed, i.e., that has one monitor per driver.
It keeps commit:8b0cd321d5a4d08ccba5845c5f2206e6f8032c1d
from breaking if an updated win-qxl driver is paired with an older client.
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1248189
---
Changed from v1: Removed a local commit that preceded this one.
---
Changed from v2: Changed name to "monitors config position"
---
|
|
Commit d0ae58a8 added spice-protocol >= 0.12.10 to the Requires.private
field in spice-client-glib.pc. However it's already present in the
Requires field without a version check. Once spice-gtk is built and
installed, building a program against spice-gtk needs spice-protocol,
but no specific version of it, so we can drop the duplicate
Requires.private requirement, and keep the unversioned one in Requires.
|
|
When a display channel is associated with a particular SpiceDisplay
widget, it previously set the display to 'enabled' unconditionally.
There is a couple of problems with this behavior.
First, simply because a display widget has an associated display
channel, it doesn't necessarily mean that the display is enabled. On
linux guests, for instance, a display channel can have up to 4 displays
for one channel, and perhaps only one of them is enabled. So, we
shouldn't set the display to 'enabled' until we actually receive a
monitors configuration message indicating that this display is enabled.
The second problem is that this was triggering the client to send down a
new monitors-config message to the server. This message is completely
unnecessary since it is triggered by a message from the server. We
should only be sending down new monitor configurations in response to
changes from the client, not from the server.
|
|
This is a new function that allows the caller to decide whether to send
the new status down to the server or not (analogous to the difference
between spice_main_set_display() vs spice_man_update_display()).
This new function is needed to reduce unnecessary MonitorsConfig
messages from being sent to the server. Because spice-gtk does not
maintain any display state internally, it depends on the application to
maintain that state. Some state changes come from the server itself
(e.g. the guest has changed resolution due to some activity within the
guest), and some come from the application (e.g. the user has resized
the window of the client). Changes that come from server updates do not
need to be sent back down to the server, whereas those that originate
from the application *do* need to be sent to the server.
|
|
Use g_get_monotonic_time() instead of g_date_time_new_now_local().
g_get_monotonic_time doesn't suffer discontinuities and it is sufficient
for our purposes. There is no need for the complexity of GDateTime.
|
|
In case audio backend is not initialized correctly or there isn't audio
in the VM, we should not try to volume-sync.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1257210
|
|
During the file transfer debug messages about the progress are printed
every 20 seconds for each of the file transfer tasks.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1140512
Acked-by: Frediano Ziglio <fziglio@redhat.com>
|
|
g_format_size_for_display is deprecated since glib 2.30. See glib commit
afd1e3697065c1bd23fe9a1cacf43d8744d0bc9b
g_format_size will be used in the following commit
Acked-by: Frediano Ziglio <fziglio@redhat.com>
|
|
Update the documentation about the return value, and how to watch for
connection success.
Releated to:
https://bugzilla.redhat.com/show_bug.cgi?id=1253848
|
|
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_
|
|
It's seeing regular releases and is API stable, so we don't need to
bundle it with spice-gtk
|
|
Currently, spice-gtk debugging logs contain no traces of the
values of the auto-redir/redir-on-connect filter, and it does not tell
you about the vid/pid of the devices being connected/redirected.
This commit adds the appropriate SPICE_DEBUG/CHANNEL_DEBUG calls so that
this data is logged.
|
|
Since v0.22~19 "Use system-wide trust certificate store", when neither
SpiceSession::ca-file nor SpiceSession::ca are set, the system-wide
CA store will be used to validate the SPICE certificates.
However, there is still a g_warn_if_fail() checking that either ca or
ca-file are set, which causes a runtime warning when trying to use the
system-wide store. This commit removes it.
|
|
Windows guest can have disabled display on the display chanel #0, in
that case it will not be listed in virt-viewer's "View->Displays" menu
Resolves:
https://bugs.freedesktop.org/show_bug.cgi?id=91489
|
|
Each monitor on a Windows guest is represented as a separate, single-headed
device with its own framebuffer. When there are multiple monitors, all
monitors but one will have a non-zero xy config position. But even in
these cases the whole area (frame-buffer) of each monitor should be
updated.
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1202419
|
|
This prevents a compile error on Debian Jessie, when building from git.
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.
|
|
The commit 4b5e6ec2114e1250c81027ebeac9cfe8d059153f introduced a function
returning gboolean, g_return_val_if_fail() should be used instead of
g_return_if_fail().
|
|
If a client (virt-manager, spicy) is not setting display dimensions
and the "resize-guest" property is disabled, spice-gtk sends a wrong
monitor config message where all the monitors have width = heigh = 0
when the agent connects. This message can confuse the guest, in that
case the guest will change the resolution of its monitor.
Regression since 28312b8d1e287a320851e8828825f2ca138d8b0b
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1240721
|
|
Windows guests with multi-monitors will often send down the same image
via different channels. If these instances are not counted, one channel
can delete an image before all the rest of the channels are finished with
it. In this case, the client will hang.
This can happen, for instance, when the Windows guest is updating the
monitor's wallpaper. There is a driver instance for each monitor, so each
one is sending down its own copy of the same image with the same id. As
one channel may be busier than another, the order that the client executes
commands may not be the same order as the server issued them. Here's what
can happen:
On the server side:
Monitor 1 sends image A
Monitor 1 sends multiple rendering commands for image A
Monitor 1 removes image A
Monitor 2 sends image A
Monitor 2 sends rendering commands for image A
On the client side:
Monitor 1 adds image A to the cache
Monitor 1 starts rendering with image A
Monitor 2 adds image A to the cache - has same id, so image is replaced
Monitor 1 removes image A - image A is completely removed from cache
Monitor 2 render command hangs waiting for image A
Addresses bug: https://bugzilla.redhat.com/show_bug.cgi?id=1194354
|
|
This will fix EL6 builds.
Christophe Fergeau (1):
m4: Add compat AS_VAR_APPEND for older autoconf
Lukas Venhoda (3):
ppc: Fix quic decode endianess
ppc: Fix lz magic endianess
ppc: Fix quic magic endianess
|
|
Indicate whether the monitors config debug output is from sending or
receiving new monitors configuration. You can tell this by looking at
which channel is involved (main vs display), but making it more explicit
is helpful for glancing through logs.
|
|
If the user prefers a specific compression algorithm, report it when
setting up the display channel.
|
|
|
|
Also, depend on the spice-common commit that introduces the
SpiceImageCompress enum.
|
