This should only be included from c files.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
The id is called 'monitor_id' throughout the rest of the code, rename
for clarity and consistency.
Signed-off-by: Lukáš Hrázký <lhrazky@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>
Client might want to choose a preferred video codec for streaming for
different reasons which having hardware decoder support being the most
interest one.
This message allows the client to send an array of video codecs in
order of preference.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Compressed message type is CompressedData which contains compression
type (1 byte) followed by the uncompressed data size (4 bytes-exists
only if data was compressed) followed by the compressed data
Update the required protocol to 0.12.12:
Signed-off-by: Snir Sheriber <ssheribe@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
libcacard.h requires 2.5.1. Keep compatibility for older versions until
the transition in distros to the standalone version is done.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
[ Christophe: add < 2.5.1 fallback ]
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
When accessing a virtual desktop from different devices, some may have
different image compression requirements, e.g. slow devices may prefer
the faster LZ4 over GLZ. This message instructs the server to switch the
image compression algorithm. This patch also promotes the
SPICE_IMAGE_COMPRESS_* constants so that they are available from both
the server and the client.
SPICE_MSG_PLAYBACK_LATENCY is intended for adjusting the
latency of the audio playback. It is used for synchronizing
the audio and video playback.
The corresponding capability is SPICE_PLAYBACK_CAP_LATENCY.
If the server & client support SPICE_DISPLAY_CAP_STREAM_REPORT,
the server first sends SPICE_MSG_DISPLAY_STREAM_ACTIVATE_REPORT. Then,
the client periodically sends SPICE_MSGC_DISPLAY_STREAM_REPORT
messages that supply the server details about the current quality of
the video streaming on the client side. The server analyses the
report and adjust the stream parameters accordingly.
A Spice port channel carry arbitrary data between the Spice client and
the Spice server. It may be used to provide additional services on top
of a Spice connection. For example, a channel can be associated with
the qemu monitor for the client to interact with it, just like any
qemu chardev. Or it may be used with various protocols, such as the
Spice Controller.
A port kind is identified simply by its fqdn, such as org.qemu.monitor,
org.spice.spicy.test or org.ovirt.controller...
The channel is based on Spicevmc which simply tunnels data between
client and server. A few messages have been added:
SPICE_MSG_PORT_INIT: Describes the port state and fqdn name, should be
sent only once when the client connects.
SPICE_MSG_PORT_EVENT: Server port event. SPICE_PORT_EVENT_OPENED and
SPICE_PORT_EVENT_CLOSED are typical values when the chardev is opened
or closed.
SPICE_MSGC_PORT_EVENT: Client port event.
rhbz #813826, #815426
Add SPICE_MSG_DISPLAY_STREAM_DATA_SIZED, for stream_data message
that also contains the size and destination box of the data.
The server can send such messages only to clients with
SPICE_DISPLAY_CAP_SIZED_STREAM.
Empty structures are undefined in C, gcc handles them without issue
assigning a size of 0. However MSVC++ generates a hard error (C2015)
this allows messages.h to be included in c files compiled by MSVC++.
Signed-off-by: Aric Stewart <aric@codeweavers.com>
Add spice_server_set_name() and spice_server_set_uuid() that allows
the client to identify a Spice server (useful to associate settings
with a particular server)
The SPICE_MSG_MAIN_NAME and SPICE_MSG_MAIN_UUID messages are only sent
to capable clients, announcing SPICE_MAIN_CAP_NAME_AND_UUID.
(1) send SPICE_MSG_MAIN_MIGRATE_BEGIN upon spice_server_migrate_connect
(to all the clients that support it)
(2) wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) from all the relevant clients,
or a timeout, in order to complete client_migrate_info monitor command
(cherry picked from commit 5560c56ef05c74da5e0e0825dc1f134019593cad branch 0.8;
Was modified to support the separation of main channel from reds, and multiple clients)
Conflicts:
server/reds.c
These messages allow the guest to send the audio device volume to the
client. It uses an arbitrary scale of 16bits, which works good enough
for now.
Save VolumeState in {Playback,Record}State, so that we can send the
current volume on channel connection.
Note about future improvements:
- add exact dB support
- add client to guest volume change
Updated since v2:
- bumped record and playback interface minor version to allow
conditional compilation
Updated since v1:
- sync record volume on connection too
Since some spice C++ code is using code from common/, the C
functions need to be marked as such for the C++ compiler, otherwise
we'll get linkage issues.
Remove all uses of @end in the marshaller, instead just using
the C struct array-at-end-of-struct. To make this work we also remove
all use of @end for switches (making them C unions).
We drop the zero member of the notify message so that we can avoid this
use of @end for a primitive in the marshaller (plus its useless to send
over the wire).
We change the offsets and stuff in the migration messages to real pointers.
Right now we always assume pointers are stored as SPICE_ADDRESS,
i.e. 64bit, independent on the size sent on the network.
This is required for 64bit architectures of course, but slightly overkill
on 32bit architectures, so needs fixing when all SPICE_ADDRESS elements
can be made internal.
We move all message structs from spice-protocol to spice as
we want to be able to change these as needed internally. The
on-network format is no longer defined by these structures anyway,
but rather by the spice protocol description.
