spice_display_channel_change_preferred_video_codec_types: new function
for sending an array of video codecs instead of only one.
Signed-off-by: Kevin Pouget <kpouget@redhat.com>
Add a few helper functions to deal with a QMP port channel, in order
to ease json handling, and wrapping a few commands.
(by convention, the port should have the name
"org.qemu.monitor.qmp.0", but it's not strictly required)
This helper is put into use in the virt-viewer "Add QEMU-like UI: VT
console & basic VM status" series.
Note: this adds a strong dependency on json-glib for
spice-client-glib, a widely available and fairly small
library.
QMP specification is:
https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/qmp-spec.txt
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Signed-off-by: Matthew Francis <mjay.francis@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1505831641-28134-6-git-send-email-mjay.francis@gmail.com>
Signed-off-by: Matthew Francis <mjay.francis@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1505831641-28134-5-git-send-email-mjay.francis@gmail.com>
Signed-off-by: Matthew Francis <mjay.francis@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1505831641-28134-4-git-send-email-mjay.francis@gmail.com>
Signed-off-by: Matthew Francis <mjay.francis@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1505831641-28134-3-git-send-email-mjay.francis@gmail.com>
Signed-off-by: Matthew Francis <mjay.francis@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1505831641-28134-2-git-send-email-mjay.francis@gmail.com>
It provides information about the remote cursor similar to the signal
"cursor-set". The benefit over the signal is that the property can be
queried at any time.
Users of the "cursor-set" signal should migrate to "notify::cursor".
Related:
https://bugzilla.redhat.com/show_bug.cgi?id=1411380
Acked-by: Victor Toso <victortoso@redhat.com>
* SPICE_MSGC_DISPLAY_PREFERRED_VIDEO_CODEC_TYPE
This message was introduced in protocol 0.12.13 to establish client
side preference on video codec to be used in streams.
At this moment, we only introduce a new API [0] to select *the*
preferred video codec for client; In a later time, it should be
possible to use this message upon connection in order to to give
higher priority for video codecs with better performance and with
hardware decoding capabilities.
[0] spice_display_change_preferred_video_codec_type()
Note that host preference for encoding is expected to be considered
first then the client's preference.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
If a client is handling multiple SpiceFileTransferTasks at one time,
it's not currently possible to provide a single overall progress to the
user. The only information that the client can get is the percentage
progress. This patch adds two new properties:
- total-bytes: the size of the file transfer task in bytes
- transferred-bytes: the number of bytes already transferred
This allows a client UI to calculate the combined progress for all
ongoing transfer tasks and present it to the user. Two convenience
functions were added to retrieve these values:
- spice_file_transfer_task_get_total_bytes()
- spice_file_transfer_task_get_transferred_bytes()
Send a SpiceMsgcMainMouseModeRequest message to request a mouse mode.
This allows to switch between client/absolute and server/relative mouse
modes.
This is necessary for some applications that require pointer
re-positioning, which we can't provide through a remote protocol easily
with client pointer (no such hardware-level message exists afaik).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Victor Toso <victortoso@redhat.com>
This commit introduces functions for asynchronous disconnection flows.
Following commits will make use of those.
Thread safety is ensured the same way it was done for connection
flow in previous commits. Disconnect logic is protected by the same
locks that protect connect/usbredir/channel management logic.
Signed-off-by: Kirill Moizik <kmoizik@redhat.com>
Signed-off-by: Dmitry Fleytman <dfleytma@redhat.com>
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Add spice-glib support for gl scanout messages.
A note about SpiceGlScanout: it is struct with scanout details,
registered as a boxed type, with associated gl-scanout property. That
way, it doesn't need a seperate signal for change notification and the
current scanout can be retrieve with gobject getter. Since boxed
property are always duplicated by g_object_get(), an additional
spice_display_get_gl_scanout() method returns the current scanout
without duplication (that's what spice-gtk display widget will use).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
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.
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.
