Rename struct VSCMsgReaderAdd field 'reader_name' to 'name', and struct
VSCMsgATR field 'data' to 'atr' to match their definitions in file
vscard_common.h.
The error log follows:
generated_server_demarshallers.c:1985:30: note: each undeclared identifier is reported only once for each function it appears in
generated_server_demarshallers.c:1994:15: error: ‘VSCMsgReaderAdd {aka struct VSCMsgReaderAdd}’ has no member named ‘reader_name’
memcpy(out->reader_name, in, reader_name__nelements);
^~
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This change does not affect generated code but make source more
readable. Also document in a single location the range of this
type.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
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 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>
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>
Without this, the demarshalling code does not know we expect exactly
SpiceMsgSmartcardData::length bytes, and has to guess it from the
amount of data which was sent
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Clients that support multiple codecs must advertise the
SPICE_DISPLAY_CAP_MULTI_CODEC capability and one
SPICE_DISPLAY_CAP_CODEC_XXX per supported codec.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
(cherry picked from spice-protocol commit 7937915d67702a5c4b5147b277c432f5555e3852)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Add 2 new messages to the display channel to stream pre-rendered GL
images of the display. This is only possible when the client supports
SPICE_DISPLAY_CAP_GL_SCANOUT capability.
The first message, SPICE_MSG_DISPLAY_GL_SCANOUT_UNIX, sends a gl image
file handle via socket ancillary data, and can be imported in a GL
context with the help of eglCreateImageKHR() (as with the 2d canvas, the
SPICE_MSG_DISPLAY_MONITORS_CONFIG will give the monitors
coordinates (x/y/w/h) within the image). There can be only one scanount
per display channel.
A SPICE_MSG_DISPLAY_GL_DRAW message is sent with the coordinate of the
region within the scanount to (re)draw on the client display. For each
draw, once the client is done with the rendering, it must acknowldge it
by sending a SPICE_MSGC_DISPLAY_GL_DRAW_DONE message, in order to
release the context (it is expected to improve this in the future with a
cross-process GL fence).
The relation with the existing display channel messages is that all
other messages are unchanged: the last drawing command received must be
displayed. However the scanout display is all or nothing. Consequently,
if a 2d canvas draw is received, the display must be switched to the
drawn canvas. In other words, if the last message received is a GL draw
the display should switch to the GL display, if it's a 2d draw message
the display should be switched to the client 2d canvas.
(there will probably be a stipped-down "gl-only" channel in the future,
or support for other streaming methods, but this protocol change should
be enough for basic virgl or other gpu-accelerated support)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
(cherry picked from spice-protocol commit 3fc2221e965623c5a7e50d95f1623269a067c2d3)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
No need to use an uint8 typed member, we can directly use the
appropriate enum8 type here, which makes everything more explicit.
(cherry picked from spice-protocol commit 8a3def14e35039753097094ba356e85e8fc2d128)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Re-using the SPICE_IMAGE_COMPRESS_ prefix in newer spice-protocol
releases is going to cause issues as there will be clashing enum members
in older spice-server releases. Using SPICE_IMAGE_COMPRESSION_ as a
prefix sidesteps these backward compability issues.
(cherry picked from spice-protocol commit e857cd9a378cdf56805b64284491a12af93a7cbf)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This reverts commit 7665dcf1bb.
Also revert the related build-sys changes to fix the build.
codegen generated code depends on spice-common code (marshaller,
messages etc), it makes more sense to keep the generator along
this. Otherwise a newer protocol release will fail to build older
projects.
*.proto files are required as well, since it generates code that parent
modules depend on unconditionnaly.
Signed-off-by: Marc-André Lureau <marcandre.lureau@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.
- Add a new LZ4 image type to spice.proto.
- Add canvas_get_lz4() to common_canvas_base, to get a pixmap from an
lz4 image.
- Add an enable-lz4 switch to the configure script, disabled by default.
This channel provides a webdav server (rfc4918). This allows various
guest or remote system that support webdav to access a folder shared by
the client (some agent can be used to proxy the requests on a local port
for example). The webdav server may also be accessed by an hypervisor as
a remote filesystem interface, which can then be accessed by the guest
via other means (fs/fat emulation, mtp device, etc)
Due to the usage of a single channel stream and the need for concurrent
requests, webdav clients streams are multiplexed. Each client stream is
framed within 64k max messages (in little-endian)
int64 client_id
uint16 size
char data[size]
A new client_id indicates a new connection. A new communication stream
with the webdav server should be started. A client stream message of
size 0 indicates a disconnection of client_id. This multiplexed
communication happens over the channel "data" message.
Only when the port is opened may the communication be started.
A closed port event should close all currently known multiplexed
connections.
Why WebDAV?
webdav is supported natively by various OS for a long time (circa
Windows XP). It has several open-source implementations and a variety of
tools exist. A webdav implementation can be tested and used without a
Spice server or any virtualization (this also permit sharing the
implementation with other projects in the future, such as GNOME). It is
an IETF open standard and thus thoroughly specified.
The basic requirements for an efficient remote filesystem are provided
by the standard (pipelining, concurrency, caching, copy/move, partial
io, compression, locking ...) While other features are easily possible
via extensions to the protocol (common ones are executable attributes,
or searching for example).
Given the requirements, and the popularity of http/webdav, I believe it
is the best candidate for Spice remote filesystem support.
Other alternatives (adhoc, p9, smb2, sftp) have been studied and
discarded so far since they do not match in term of features or
requirements.
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.
Add a new arbitrary keyboard scancodes message.
For now, it will be used to avoid unwanted key repeatition when there
is jitter in the network and too much time between DOWN and UP
messages, instead the client will send the press & release scancode in
a sequence.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=812347
Define different enums that have a SPICE_ prefix to not conflict with same
value enums from libcacard/vsccard_common.h, and continue to use the same
SPICE_MSG_SMARTCARD_DATA and SPICE_MSGC_SMARTCARD_DATA enum that is used by the
server and clients (spice-gtk, spicec) alike.
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.
It turned out the demarshaller wasn't allocating enough space to
memcpy the name. In order to take into account the size of a variable
array, it needs to be marked with the @end tag so that the
"extra_size" is added to the allocated memory.
It would be nice if the demarshaller would somehow fail if this wasn't
set explicitly, or do the right thing by default.
@end the name so that demarshaller
We don't want to conditionally compile the smartcard messages
depending on whether USE_SMARTCARD is set or not, we can now use
the @ifdef attribute for that.
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.
With the new usbredir code we have the new concept of the abstract /
generic spicevmc channel type (which just tunnels data from a qemu chardev),
and we've the usbredir channel, which is the only current user of this.
This was reflected in the protocols enum in spice-protocol.h by a manual
edit done by me, my bad. This patch teaches spice.proto about the relation
between the abstract spicevmc channel and the usbredir channel and
modifies codegen to deal with this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(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
