spice-protocol (0.14.1-1) unstable; urgency=medium
* Team upload.
* New upstream release
* debian/gbp.conf: Enable pristine-tar
* Bump Standards-Version to 4.5.0 (no further changes)
* Bump debhelper compatibility to 12
spice-protocol (0.14.0-1) unstable; urgency=medium
* Team upload.
[ Ondřej Nový ]
* d/copyright: Change Format URL to correct one
* d/changelog: Remove trailing whitespaces
* d/control: Remove trailing whitespaces
[ Laurent Bigonville ]
* Enable upstream tarball signature verification
* New upstream version 0.14.0
* debian/docs: Dropped, the NEWS file has been renamed to CHANGELOG.md and
is now installed by dh_installchangelogs
* debian/control: Bump Standards-Version to 4.4.0 (no further changes)
According to C standard the size of a structure without fields is
not defined (see
https://stackoverflow.com/questions/21851930/size-of-empty-structure-in-c-and-c).
As we almost only use GCC currently these structures are of size 0.
This can became a problem if 2 sides talking a given protocol use
these structures.
To avoid such possible mismatch (for instance having one side C and
the other C++ which defines these structures as having 1 as size) add
an empty (0-size array) field.
Although a 0-size array is not considered also that portable we use
extensively this feature with different compilers never encountering
issues.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
This definition is lacking in client while in server it is hardcoded
to 50. Having a well defined limitation allow us to make the code
more robust and optimized.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
It is a duplicate information in a place where it is not necessary and
of little value.
Signed-off-by: Lukáš Hrázký <lhrazky@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Depending on how structures are initialised in the code is
possible that implicit padding bytes are not initialised
causing possible information leaks as the entire structure
with all padding is sent through device/network.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe de Dinechin <dinechin@redhat.com>
GCC introduced __builtin_bswapXX intrinsics in a quite old
version.
As version 2 and 3 are no more used nowadays instead of manually
craft these functions using assembly language use the new built-ins.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@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>
Clarify that this value specifies the size in bytes, not the number of
capabilities.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This message is specified to have a size limit of 1024, so provide this
as a #define
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Christophe de Dinechin <dinechin@redhat.com>
This allows to better support client mouse using streaming device
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe de Dinechin <cdupontd@redhat.com>
This protocol allows a guest to send a video stream to the server.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe de Dinechin <cdupontd@redhat.com>
Introduce new error statuses to report more info to clients:
VD_AGENT_FILE_XFER_STATUS_SESSION_LOCKED,
VD_AGENT_FILE_XFER_STATUS_VDAGENT_NOT_CONNECTED,
VD_AGENT_FILE_XFER_STATUS_DISABLED
These are only sent to clients that feature
VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS capability.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Agent can send VDAgentFileXferStatusMessage with result
VD_AGENT_FILE_XFER_STATUS_NOT_ENOUGH_SPACE to indicate lack of free
space. This enables more detailed error reporting, so the user knows
why the file transfer has failed.
Add VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS to ensure detailed errors
are not sent to clients that do not support it. This can be used
with more file xfer errors in the future.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
This allows the header to be used in no GPL programs.
Others headers are already MIT licensed so this change do
not require additional changes to already existing
programs.
The file can be generated with
./spice_codegen.py -e spice.proto --license MIT enums.h
from spice-common.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@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 a list of video codecs in a
order of preference.
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This gains us automatic support for whichever compilers GLib supports in
this macro when used in projects that use GLib.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
This header is auto generated from spice_codegen.py tool in
spice-common repository and thus, it changes what was included
manually.
Move SpiceDataCompressionType struct to comply with spice_codegen.py.
This header was generated with:
./spice_codegen.py -e spice.proto ../spice-protocol/spice/enums.h
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Codegen generates code specific to spice-common submodule. It's not
meant as a generic protocol header or specification. See discussion and
commits about spice-common codegen re-import.
Signed-off-by: Marc-André Lureau <marcandre.lureau@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>
This prevents incompatibility if users (like old spice-server/spice-gtk)
are not expected to have this additional restriction.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This patch is a left-over from the fd passing commit 267391c8fd as
suggested by Frediano Ziglio during review.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Frediano Ziglio <fziglio@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>
Add a new type, "unix_fd", used to describe file descriptor sharing via
socket ancillary data (these messages are local only).
The marshaller/demarshaller can't serialize this in memory (consume_fd
implementation is empty), so it is the responsability of the marshaller
user to handle sending and receiving the handles, which are appended at
the end of the message with an extra stream byte (because some Unix
requires sending at least a byte with ancillary data).
Even if there is no fd to send (or if the fd is invalid etc), the
receiver side expects an extra byte anyway.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Check the pointer given is the same type as member pointer.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
So we can avoid using using an attribute not supported for the compiler.
warning:
../spice-common/common/mem.h:91:80: warning: unknown attribute
'__alloc_size__' ignored [-Wunknown-attributes]
void *spice_malloc0_n(size_t n_blocks, size_t n_block_bytes)
SPICE_GNUC_MALLOC SPICE_GNUC_ALLOC_SIZE2(1,2);
../spice-common/spice-protocol/spice/macros.h:52:52: note: expanded
from macro 'SPICE_GNUC_ALLOC_SIZE2'
#define SPICE_GNUC_ALLOC_SIZE2(x,y) __attribute__((__alloc_size__(x,y)))
^
GCC 4.4.7 does not define __BYTE_ORDER__ macros so use architecture
macro to attempt to detect endianess.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Reported-by: Swapna Krishnan <skrishna@redhat.com>
Tested-by: Swapna Krishnan <skrishna@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>
This macro allow to define magic constants without using weird
memory tweacks.
This remove some possible warning from some compiler and
make code more optimized as compiler is able to compute the
constant.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Files listed as _DATA in Makefile.am are installed without the
executable bit set, files listed as _SCRIPT do get the executable bit
set. As spice_codegen.py is meant to be run by spice-protocol users,
make sure this bit is set.
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.
spice-common generate code from these python scripts and the installed
SPICE .proto. This commit installs them during make install, and adds a
codegendir variable to the pkgconfig file so that spice-common can
locate the scripts.
This flag is only used for git builds, and can usually safely be
disabled.
When it's enabled, configure.ac will check that python-six and pyparsing
are available, and will use these together with the codegen python
scripts in order to automatically regenerate enums.h when the .proto
files change.
The just added .proto files and python code generation code need to be
added to EXTRA_DIST in order to be distributed in tarballs, and
we need to recurse in the new python_modules directory.
This patch changes the type of 'valid_attributes' and
'attributes_with_arguments'.
Both of them are list of different strings and are kept in sets.
This was the intention of the original code, but this patch
use a specific set([ strings ]) format, instead of { strings }.
This fixes the build for me on RHEL-6 (python-2.6.6).
Build error is:
File "/home/ulublin/git/spice/spice-common/python_modules/ptypes.py",
line 67
'end',
^
SyntaxError: invalid syntax
Having these constants use the same name as the ones in spice-server
0.12.5 causes compilation issues for spice-server users when using
spice-server 0.12.5 or older, and spice-protocol 0.12.8.
This is to prepare to generate the wireshark dissector which uses
glib types instead of the newer C ones (for compatibility with some
compilers).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Verify that the attribute is known. This could help for instance to
avoid some future typo mistakes.
We also now have a list of attributes that we can comment for
documentation purpose.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Trying to generate enums.h with python3 results in
Traceback (most recent call last):
File "./spice_codegen.py", line 217, in <module>
write_enums(writer, options.generate_dissector)
File "./spice_codegen.py", line 99, in write_enums
write_channel_enums(writer, c, False, False)
File "./spice_codegen.py", line 17, in write_channel_enums
if len(messages) == 0:
TypeError: object of type 'filter' has no len()
filter() returns an enumerator object in python3 while it used to return
a list in python2. Using list(filter()) instead fixes that error.
I've checked that the generated enums.h is identical with python2 and
python3.
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.
This allows spice-protocol users to depend on the git version.
spice-vdagent.git needs a spice-protocol version newer than the latest
release for the volume synchronization work or it won't build.
With VD_AGENT_AUDIO_VOLUME_SYNC the client can send volume and mute
values to be set in the guest for input or output devices.
Currently this is done once after the agent send its capabilities.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1012868
Older versions of python-six (at least 1.3.0) defined six.PY3 but not
six.PY2. six.PY2 is only used twice in straightforward tests so it's
easy to use six.PY3 instead.
This is a new version of my previous patch that does not include six.py.
It's still kind of big, but at least it's all spice-common changes now.
There are also a few other fixes that Christophe brought to my attention.
Note that six now needs to be installed on the system (python-six on
Fedora and Debian, six on PyPI).
This *should* be enough to make spice_codegen.py work on both Python 2
and Python 3. The major changes are as follows:
* cStringIO.StringIO -> io.StringIO
* str vs. unicode updates (io.StringIO doesn't like str)
* integer division
* foo.has_key(bar) -> bar in foo
* import internal_thing -> from . import internal_thing
* removed from __future__ import with_statement
(might break Python 2.5?)
* changed some lambdas to list comprehensions (done by 2to3)
* cast some_dict.keys() to list where needed (e.g. for sorting)
* use normal type names with isinstance instead of types.WhateverType
Signed-off-by: Alexander Wauck <awauck@codeweavers.com>
- 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.
The return of the get_array_size() is used as a limit in a loop,
being compared with an unsigned index (indexes are always unsigned).
To avoid the -Wsign-compare warning, let's cast the return of the
get_array_size() to unsigned and make GCC happier.
Although the most part of the parameters marked as unused are actually
being used for a few functions, a bunch of warnings can be seen when
the code is compiled with "-Wall -Wextra". As adding the unused attribute
means that the variable/parameter is meant to be *possibly* unused, we're
safe adding it in the generated code, even for used variables/parameters.
Since the (de)marshallers are now generated in $builddir and not in
$srcdir, when these generated files include a file located in
$srcdir/common, the compiler will find them thanks to a -I directive, so it
makes more sense to use <> rather than "" when including them.
Now that they are created in $builddir, their includes will need to refer
to files in $srcdir, which can be different. It's cleaner to add
-I $(top_srcdir)/spice-common/ to modules using spice-common rather than
having -I $(top_srcdir)/spice-common/common which would could create header
collisions.
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.
Add an optional message sent by the client to ask the agent not to send
clipboard data bigger than a certain size, in bytes. The message can be
sent if the agent supports the capability MAX_CLIPBOARD, at any time.
The agent is free to ignore or forget the value after a restart or a
disconnection, but a bigger message might be discarded when received on
client side, resulting in bandwidth waste.
There is no use for those 2 values, and the default limit would be quite
wrong.
Put them in a deprecated block. If someone uses them, he will have to
add -DSPICE_DEPRECATED, or just fix the code.
Use same license as spice-gtk and spice modules (LGPL 2.1) since those licenses
applied to the spice-common submodule in the past. This makes it more clear
that if you use spice-common separately, the license is still LGPL. Also
mention license and copyright in generated files.
The wireshark protocol dissector is a bit out-of-date. Several new channel types
and enums have been added. It would be nice if these values (and the
translation between the value and the name) could be automatically generated so
that updating the dissector was a slightly less manual process. This patch adds
a commandline switch which generates both the enums and value-name lists in the
format that wireshark expects.
When copy and pasting between a Linux guest and a Windows client or visa
versa, the line-endings of the text will usually be wrong for the other side,
so it is desirable to do automatic conversion.
However sometimes it is possible for text in the clipboard on Linux to have
MSDOS (CRLF) style line-endings, when copy and pasting from Linux to Linux
it is undesirable to automatically convert these, since this would not happen
when the apps were running directly on the same machine.
So we want to do automatic conversion only if the client and guest native
line-endings differ. This means that we cannot simply define one standard
line-ending for VD_AGENT_CLIPBOARD_UTF8_TEXT data.
Given the above it makes sense to only do conversion on one end. This
patch adds new capabilities which allow the guest-agent to advertise what
is the native line-ending of the guest.
This should be used by the client in the following way:
1) Check if the guest-agent advertises any line-ending type at all, if not
the guest line-ending is unknown -> do not convert
2) If the guest's native line-ending matches that of the platform the client
is running on, then do no not convert
3) If the guest's native line-ending is different from the client platform,
then convert received clipboard data into the client platform's native
line-ending, and convert clipboard data which will be send to the guest-agent
into the guest's native line-ending.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
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.
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.
Client -> agent messages can spawn multiple VDIChunks. When this happens
the agent re-assembles the chunks into a complete VDAgentMessage before
processing it. The server only guarentees coherency at the chunk level,
so it is not possible for a partial chunk to get delivered to the agent.
But it is possible for some chunks of a VDAgentMessage to be delivered to
the agent followed by a client to disconnect without the rest of the
VDAgentMessage being delivered!
This will leave the agent in a wrong state, and the first messages send to it
by the next client to connect will get seen as the rest of the VDAgentMessage
from the previous client.
This patch introduces a new VD_AGENT_CLIENT_DISCONNECTED message which the
server will send from the VDP_SERVER_PORT on client disconnect, on which the
agent can then reset its VDP_CLIENT_PORT state.
Note that no capability is added for this, since capabilities are tracked
between the client and the agent only. The server will simply always send
this message on client disconnect, relying on older agents discarding the
message since it has an unknown type (which both the windows and linux agents
already do).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Currently the sender of a file xfer assumes success on having send the
last data bytes. But the transfer may still fail on the other side.
This commits adds a VD_AGENT_FILE_XFER_STATUS_SUCCESS result value instead.
Since we have not done an agent release with file-xfer support yet, the client
code can simply assume that it will always get *a* VD_AGENT_FILE_XFER_STATUS_
message for a transfer now. As for the existing spice-gtk release with
file-xfer support, if it talks to an agent sending this message, this will
trigger a g_return_if_fail, which is not really pretty, but has no negative
side-effects other then an error message being logged.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add a new string message for sending proxy details.
CONTROLLER_PROXY (ControllerData, string)
The value must be of the form [protocol://]<host>[:port]
The proxy string may be specified with a protocol:// prefix to specify
alternative proxy protocols.
If no protocol is specified in the proxy string or if the string
doesn't match a supported one, the proxy will be treated as a HTTP
proxy.
Currently the agent expect a monitor config to be continuous. If the user has
3 monitors (3 spice display windows) open and tries to disable the 2nd one,
then instead of the 2nd one being closed, the 3th one ends up closed.
To be able to fix this we need to be able to send a sparse monitor config
to the agent. A monitor being disabled in such a sparse config is simply
represented by its width and height being 0 in its VDAgentMonConfig.
Since old versions of the agent won't be capable of dealing with such a
0x0 sized monitor, this patch adds a new VD_AGENT_CAP_SPARSE_MONITORS_CONFIG
capability to signal to the client that the agent understands this, and
the client should only send sparse monitor configs to agents with this
capability.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
At present, Vmware and Virtualbox has supported file drag&drop feature,
I think it's a good feature for users, so we want qemu/spice to
supports it.
This patch first adds communication protocol between client and guest,
we must make the agent protocol stable before coding, this is what we
want this patch to do.
This feature has been discussed on spice mailing list.
The more details are available at following pages:
http://lists.freedesktop.org/archives/spice-devel/2012-November/011400.html
and
http://lists.freedesktop.org/archives/spice-devel/2012-November/011485.html
Signed-off-by: Dunrong Huang <riegamaths@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Alon Levy <alevy@redhat.com>
Cc: Uri Lublin <uril@redhat.com>
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.
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.
(See related spice.proto change in spice-common)
So far we have used the agent to notify the guest of a request to change
the monitors configurations (heads) on the qxl device. This patch introduces
a new interrupt and new fields in the qxl rom to notify the guest about
a new request, similarly to how physical hardware notifies the driver.
We compute crc over the monitors configuration to avoid host-write from a
following update while guest-read corruption. The update protocol is:
qemu:
(2) fill QXLRom::client_monitors_config
(3) raise QXL_INTERRUPT_CLIENT_MONITORS_CONFIG
guest:
(1) clear QXL_INTERRUPT_CLIENT_MONITORS_CONFIG bit in irq status
(2) read QXLRom::client_monitors_config
(3) (verify-crc)? done : goto 2
If the interrupt mask is ~0 or 0, or does not have
QXL_INTERRUPT_CLIENT_MONITORS_CONFIG set, we also assume it doesn't support
this interrupt.
The client_present field is a byte that is set of non-zero when a
client is connected and to zero when no client is connected.
The client_capabilities[58] array contains 464 bits that indicate the
capabilities of the client. Each bit corresponds to a
SPICE_DISPLAY_CAP_* capability. In particular, if the client has
capability C, then bit (C % 8) in byte (C / 8) is set. The capability
bits only have a defined meaning when a client is connected, ie., when
client_present is non-zero. The number 58 was chosen to fill out a
cache line in QXLRom.
A new QXL_INTERRUPT_CLIENT interrupt is defined, which will be raised
whenever a client connects or disconnects.
Even though the ability to handle a8 surfaces was added at the same
time as the composite command, they are logically separate, so add a
capability bit to indicate the presence of a8 surfaces.
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
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 from a single message.
If the server doesn't support INPUTS_CAP_KEY_SCANCODE, the client is
responsible to handle a fallback mode with the exisiting KEY_DOWN and
KEY_UP messages.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=812347
The main difference between semi-seamless and seamless migration is that
while in semi-seamless migration the state of all the channels is
being completely reset after migration is complete, in seamless migration
the essential parts of the state are restored on the server side, and
are left the same on the client side. semi-seamless migration is
equivalent to having the client disconnect from the src and connected
from scratch to the dest, with the exception, that the handshake with
the dest server occurs before the client has disconnected from the src.
In semi-seamless migration in-flight data gets lost, e.g., a file
transfer to a usb device might be disrupted.
=======================
===protocol details====
=======================
Let s1, s2, and c be the src server, dest server and client, respectively.
Semi-Seamless migration protocol
================================
pre-migration phase:
--------------------
(1) s1->c: SPICE_MSG_MAIN_MIGRATE_BEGIN
In response, c tries to establish a connection to s2. After the connection is
established, it is inactive (the client doesn't attempt to read or
write messages from/to it)
(2) c->s1: SPICE_MSGC_MAIN_MIGRATE_CONNECTED or
SPICE_MSGC_MAIN_MIGRATE_CONNECT_ERROR
post migration phase:
---------------------
(1) s1->c: SPICE_MSG_MAIN_MIGRATE_END or
SPICE_MSG_MAIN_MIGRATE_CANCEL
In case of the former, c disconnects from s1, resets all its
channels states and switches to an active connection with s2.
(2) c->s2: SPICE_MSGC_MAIN_MIGRATE_END
The msg signals that all the channels have been migrated successfully to s2.
Seamless migration protocol
===========================
pre-migration phase:
--------------------
In case qemu/libvirt/client do not support seamless migration,
s1 takes the semi-seamless pathway for migration. Otherwise:
(1) s1->c: SPICE_MSG_MAIN_MIGRATE_BEGIN_SEAMLESS (*New*)
The msg includes the version of the migration protocol
of s1.
In response c tries to establish a connection to s2.
(2)
If the connection fails:
(2.1) c->s1: SPICE_MSGC_MAIN_MIGRATE_CONNECT_ERROR
If s2 supports SPICE_MAIN_CAP_SEAMLESS_MIGRATE:
(2.2) c->s2: SPICE_MSGC_MAIN_MIGRATE_DST_DO_SEAMLESS (*New*)
The msg includes the version of the migration protocol
of s1. The msg is used for querying s2 if seamless migration
is possible, given the migration protocol version of s1.
(2.2.1) s2->c: SPICE_MSG_MAIN_MIGRATE_DST_SEAMLESS_ACK/NACK (*New*)
(2.2.2) c->s1: SPICE_MSGC_MAIN_MIGRATE_CONNECTED_SEAMLESS (*New*) or
SPICE_MSGC_MAIN_MIGRATE_CONNECTED
The latter is sent when c receives SEAMLESS_NACK, and
indicates s1 to apply semi-seamless protocol on post
migraion phase.
If s2 does not support SPICE_MAIN_CAP_SEMI_SEAMLESS_MIGRATE:
(2.3) c->s1: SPICE_MSGC_MAIN_MIGRATE_CONNECTED
(see 2.2.2)
post migration phase:
---------------------
While the pre migration phase was conducted by the main channel, this
phase's protocol occurs in all the migrated channels.
(1) s1->c: SPICE_MSG_MIGRATE
The msg marks the client that the connection is paused from s1 side, and
next to this msg, the only possible msg s1 can send is
SPICE_MSG_MIGRATE_DATA
msg optional flags:
(a) MIGRATE_FLUSH_MARK
This flag is required for finalizing the channel connection
without losing any in-flight data.
This flag indicates that s1 expects SPICE_MSGC_MIGRATE_FLUSH_MARK,
for signaling that c will pause the connection and not send any more messages
to s1.
(b) MIGRATE_DATA
The flag indicates that c should receive from s1
SPICE_MSG_MIGRATE_DATA
(2) c->s1: SPICE_MSGC_MIGRATE_FLUSH_MARK (if required)
c pushes the msg to the head of its output msg queue,
and sends it before all its other pending msgs - they will be sent to s2
later.
(3) s1->c: SPICE_MSG_MIGRATE_DATA (if required)
The msg contains all the data that the server requires for restoring
the channel's state on s2 side correctly.
(4) c disconnects the channel from s1 and switches to an active connection
with s2.
(4) c->s2: SPICE_MSGC_MIGRATE_DATA
Similarly to SPICE_MSG_AGENT_CONNECTED, the msg notifies the main
channel about attaching an agent. In addition the msg also contains the
number of tokens allocated to the client.
This new command is intended to be used for implementing the Composite
request from the Render X extension. See
http://www.x.org/releases/current/doc/renderproto/renderproto.txt
for a description of the Render extension.
Composite has three fields: src, mask and destination, of which mask
is optional (can be NULL). There are also two pointers to
transformations, one for each of src and mask.
The command also has 32 bits of flags which indicates
- which compositing operator to use
- which filters to apply when sampling source and mask
- which repeat mode to apply when sampling source and mask
- whether the mask should be considered to have 'component alpha'
- whether the alpha channel of any of the images should be ignored.
The last one of these features is necessary because in the X protocol
an offscreen surface is simply a collection of bits with no visual
interpretation. In order for Render to use these bits, a wrapper
object is used that contains the pixel format. Since one offscreen
surface can be wrapped by multple objects, there is not a one-to-one
correspondence between pixel formats and surfaces.
In SPICE surfaces do have an associated pixel format, which means the
above feature of Render cannot be supported without adding a similar
concept to the wrapper object to the SPICE protocol. However, the most
common use for having multiple wrappers for one offscreen surface is
to interpret an alpha surface as not having an alpha channel or vice
versa.
Adds on device:
RAM
Header
monitors_config - pointer
QXLMonitorsConfig
count == n
max_allowed = N >= 0
QXLHead 1
...
QXLHead n
id, surface_id, x, y, width, height, flags
IO:
QXL_IO_MONITORS_CONFIG
server flushes command ring, then calls server callback for changing monitors config.
New revision to let the driver know about the new io:
QXL_REVISION_STABLE_V12=0x04,
Adds server/client capability:
SPICE_DISPLAY_CAP_MONITORS_CONFIG
Server message will be added in spice-server and spice-common.
Version is bumped to 0.12.0 to indicate new IO and structs
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.
Fixes the resulting enums.h from the invocation of:
./spice_codegen.py --generate-enums spice.proto spice-protocol/spice/enums.h
Right now any enum will contain None as the enum members, with this fix
it will contain the real enum members, i.e. SPICE_FOO.
QXL_ESCAPE_SET_CUSTOM_DISPLAY is Windows specific message
to tell the display & miniport driver to update the mode
table with a custom resolution.
The mode table needs to be forcefully refreshed after
setting a custom display, it can be done by querying an
invalid/unknown mode:
EnumDisplaySettings(dev_name, 0xffffff, &tempDevMode);
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.
rhbz #815422
Add SPICE_MSG_DISPLAY_STREAM_DATA_SIZED, for stream_data message
that in addition to the mjpeg data, also contains the
(1) width and height of the compressed frame.
(2) the destination box of the frame.
The server can send such messages only to clients with
SPICE_DISPLAY_CAP_SIZED_STREAM.
When playing a youtube video on Windows guest, the driver sometimes sends
images which contain the video frames, but also other parts of the
screen (e.g., the youtube process bar). In order to prevent glitches, we send these
images as part of the stream, using SPICE_MSG_DISPLAY_STREAM_DATA_SIZED.
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.
Before this patch, if a channel is defined conditionally in spice.proto
(because it depends on external headers like the smartcard channel),
spice_codegen would write an entry to the channels array in
spice_get_*_channel_parser which would only take up a place in the array
if the ifdef condition is true, thus moving up all other intializers
one place when it is not true. This was causing issues (crashes) when building
spice-gtk with the combination of usbredir support enabled and smartcard
support disabled.
This patch fixes this by adding #else { NULL, 0 }, to the generated code.
Thanks to coolper chen <lixin.chen@saicocch.com> for reporting this!
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
We want to be able to add an @ifdef annotation to optional messages
For example, we want to compile in the smartcard messages only if
libcacard is available
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.
A message with a fixed-size array, such as uint8 uuid[16] will
generate an invalid code, missing the __nelements variable. Make sure
that variable is defined.
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
7e30572ab adds a #include <config.h> to the beginning of generated
files. It also does this for generated headers and enums files,
which is not wanted, especially if it's an installed file. This
commit only adds this include for the non-header non-enum case
(hopefully, enums are only generated for use in a .h file).
Check both in configure.ac (after checking if we need to rebuild
the marshalling files) and in the python script using pyparsing
(for people modifying .proto files in tarballs)
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
Commit 9d5ef9beec in spice-protocol
introduced a typedef manually in the generated enums.h header.
This patch adds them automatically to all enums during enums.h generation.
For not too old spice-migration, minor is 1.
For older (ancient) spice-migration, minor is 0.
Affects only VM migration while a spice client is connected.
python_modules/demarshal.py and marshal.py fixes for gcc 4.6.0
warning about set but unused variables. The fixes disable creating
of variables mem_size when they are not used (demarshall) and
declaring a src variable when the message doesn't use it (marshal).
You need to touch *.proto after applying this (should add a Makefile
dependency).
Patch adds a "from __future__" import that doesn't affect newer python's but
allows python 2.5.4 to run the code (tested under scratchbox, n900 build environment)
It turns out that using base + sizeof(struct) is not a good way to
access an array at the end of a struct. For SpicePalette sizeof is 16, but
offset of ents is 12. Using this calculation in the demarshaller breaks
things badly, so now we use the actual array member.
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.
Even for is_extra_size() we should calculate the mem_size for
arrays, its just that the parent type (in this case switch) should
request mem_size if the type is_extra_size.
Internally and in the network protocol (for the new version) we
now store the actual number of segments rather than the size of the
full segments array in bytes. This change consists of multiple changes
to handle this:
* Make the qxl parser calculate num_segments
* Make the canvas stroke code handle the new SpicePath layout.
* Fix up is_equal_path in red_worker.c for the new layout
* replace multiple calls to spice_marshall_PathSegment with a single
spice_marshall_Path call
* Make the byte_size() array size handling do the conversion from
network size to number of elements when marshalling/demarshalling.
* Update the current spice protocol to send the segment count rather than
the size
* Update the old spice protocol to use the new byte_size functionallity
to calculate the size sent and the number of elements recieved
A @c_ptr pointer is stored in memory as a real pointer rather than a
SPICE_ADDRESS. This is a temporary thing that will be removed again
when all SPICE_ADDRESSes have been converted to real pointer.
This makes the protocol more compact. This was mainly done for the commonly
used types. Some seldom used ones are still 32bit for future compatibility.
This means the member is not sent on the network at all.
Instead its initialized to the attribute argument when demarshalled.
This is useful for backwards compatibility support.
This is required because we don't want to free messages that just
refer to the unparsed message (like SpiceMsgData).
Also, in the future we might need it for more complex demarshalling.
The "spice.proto" file describes in detail the networking prototcol
that spice uses and spice_codegen.py can parse this and generate
demarshallers for such network messages.
This allows a client to identify a Spice server. This can be useful to
associate data/configuration with this particular server.
The corresponding main channel messages are:
message {
uint8 uuid[16];
} uuid;
message {
uint32 name_len;
uint8 name[name_len] @end @nomarshal; \* \0 terminated *\
} name;
Those messages are sent by the server only if the capability
SPICE_MAIN_CAP_NAME_AND_UUID is available on the client, and the
server has the relevant data.
-Add SpiceMiniDataHeader.
-Introduce capability SPICE_COMMON_CAP_MINI_HEADER.
The advantage of using a header without sub list is to spare the 4 bytes that were sent
for a lot of messages without sublist.
Instead, messages that previously contained sub lists, will be split to two msgs.
The first one will be SPICE_MSG_LIST, holding the sub list, and the second will be the
main msg.
When most of the messages do not contain sub lists, the overhead of the additional 10 bytes
for the header of SPICE_MSG_LIST is negligible. In addition, if there is
only one message in the list, it can be sent independently.
Instead of sending the serial number of the messages, the client and
the server will increment local counters upon sending/receiving a
message.
- enums.h was generated from spice.proto
* as a result SPICE_CHANNEL_USER_DEFINED_START, which was added
manually, was removed. It is not used yet. If it is going to be used it
can be added to protocol.h in the future.
- The new msg body is SpiceSubMessageList
From SHM_OPEN(3):
For portable use, a shared memory object should be identified by a name
of the form /somename; that is, a null-terminated string of up to
NAME_MAX (i.e., 255) characters consisting of an initial slash,
followed by one or more characters, none of which are slashes.
While discussing various things with Alon in Vancouver, it came up that
having a channel which simply passes through data coming out of a qemu
chardev frontend unmodified, like the usbredir channel does, can be used
for a lot of other cases too. To facilitate this the usbredir channel code
will be turned into a generic spicevmc channel, which is just a passthrough
to the client, from the spicevmc chardev.
This patch renames the msg types to make clear that they are not usbredir
specific, but instead are generic spicevmc data passthrough messages. The
usbredir channel id is unmodified by this, although the same code and
messages can now be used for multiple purposes, we still need unique ids
for each purpose, so that the client knows how to interpret / represent the
passed through data.
Some examples of why having a generic spicevmc pass through is good:
1) We could add a monitor channel, allowing access to the qemu monitor from
the spice client, since the monitor is a chardev frontend we could re-use
the generic spicevmc channel server code, so all that is needed to add this
(server side) would be reserving a new channel id for this.
2) We could allow users to come up with new channels of their own, without
requiring qemu or server modification. The idea is to allow doing something
like this on the qemu startup cmdline:
-chardev spicevmc,name=generic,channelid=128
To ensure these new "generic" channels cannot conflict with newly added
official types, the must start at the SPICE_CHANNEL_USER_DEFINED_START value
this patch adds (128 or higher).
These new user defined channels could then either be used with a special
modified client, with client plugins (if we add support for those), or
by exporting them on the client side for use by an external ap, see below.
3) We could also add support to the client to make user-defined channels
end in a unix socket / pipe, allowing handling of the data by an external app,
we could for example have a new spice client cmdline argument like this:
--custom-channel unixsocket=/tmp/mysocket,channelid=128
This would allow for something like:
$random app on guest -> virtio-serial -> spicevmc chardev ->
-> spicevmc channel -> unix socket -> $random app on client
4) On hind sight this could also have been used for the smartcard stuff,
with a 1 channel / reader model, rather then the current multiplexing code
where we've our own multiplexing protocol wrapper over the libcacard
smartcard protocol.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The driver will check for this revision or higher to know that the device
supports async io, the two S3 related ios, and the interrupts IO_CMD and ERROR.
related RHBZ: 688883
Guest initiated sleep looks like this:
Guest:
(0) stop putting new commands into the rings
(1) QXL_IO_FLUSH_SURFACES
qxl calls flush_surfaces(), spice-server flushes command rings and
renders all surfaces, thereby flushing state to device memory.
(2) QXL_IO_DESTROY_ALL_SURFACES
zap surfaces
(3) QXL_IO_FLUSH_RELEASE
push release queue head into the release ring, so the guest
will see it and can release everything.
(4) tell acpi to reset
Qemu:
(5) qxl_reset_handler
Guest:
(6) sends surface create commands
The QXL_IO_FLUSH_SURFACES is an optimization, to reduce vmexits. It is used to
flush both command rings and update all surfaces at once (equivalent to
UPDATE_AREA X NUM_ACTIVE_SURFACES)
destroy all surfaces to release resources but not destroy the guest side surfaces
get device to flush all server released resources to the release ring (could use multiple
calls to OOM - but this is not well defined, would need to loop)
After (1) there will be no memory allocated on the pci bars.
Add async versions of the I/O commands which do not block and instead
raise the new QXL_INTERRUPT_IO_CMD when done.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
These changes the protocol the following way:
When the client announces it has SPICE_PLAYBACK_CAP_VOLUME, the server
can send PlaybackChannel.{volume,mute} messages to notify of volume
changes (respectively for RECORD).
If the client doesn't implement SPICE_PLAYBACK_CAP_VOLUME, the server can
handle the volume changes the way it prefers, for example, ignoring them or
applying volume effect on the server side etc..
needed for spice/common files used by the client, server & qxl driver.
in windows _inline works for both c/c++, while inline is c++ only.
compiling the client with mixed c/c++ code required this define.
spice-protocol comes with 2 headers to handle structure packing,
but controller_prot.h and foreign_menu_prot were both using their
own preprocessor definitions to handle packing. It's better to have
structure packing macros centralized since how it's done varies
between compilers, so it may need to change over time.
Add a new capability VD_AGENT_CAP_CLIPBOARD_SELECTION.
When both client and servers have this capability, the
VDAgentClipboard* messages MUST be prepended with a uint8_t indicating
which clipboard selection to operate + 3 bytes stuffing for alignment
that could be used for future capabilities or extensions.
A few clipboard selection are defined according to X11/Gtk scheme:
- VD_AGENT_CLIPBOARD_SELECTION_CLIPBOARD: the default clipboard,
implemented by most OS to deal with explicit Copy/Paste operations.
- VD_AGENT_CLIPBOARD_SELECTION_PRIMARY: the PRIMARY clipboard, used
for mouse selections.
- VD_AGENT_CLIPBOARD_SELECTION_SECONDARY: the SECONDARY clipboard.
See also:
http://www.freedesktop.org/wiki/Specifications/ClipboardsWikihttps://bugs.freedesktop.org/show_bug.cgi?id=34833
Current version 2.0 of the SPICE protocol describes how the client
reply to the server SpiceLinkReply message with a RSA_public_encrypt()
of the password.
Instead of using the current Spice AUTH mechanism, we would like to
offer different AUTH mechanisms, in particular SASL, which is a
framework allowing different underlying mechanisms such as
GSSAPI/Kerberos v5 (and optionally adding a data security layer).
We could bump the protocol version, but that would make this feature
mandatory for the implementer of the protocol. By using the channel
caps, the client and server are left to negotiate and alter the AUTH
part of the protocol as follows:
- SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION, if set, the authentication
mechanism can be chosen during link phase. If both client and server
have this cap, the client MUST reply to SpiceLinkReply with a
SpiceLinkAuthMechanism message, with the value of the CAP_AUTH
mechanism choosen (a uint32 auth_mechanism). The following
authentication steps are described by the selected authentication
mechanism.
The differents mechanisms selectable via
SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION are also specified as part of
the common channel caps. They can be used only if both client and
server offer them.
Ex: no AUTH selection
C: SpiceLinkMess
S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION not in common caps
- The client can't choose AUTH, and fallback on Spice RSA mechanism
Ex: AUTH selection
C: SpiceLinkMess, CAP_PROTOCOL_AUTH_SELECTION in common caps
S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION in common caps
- The client MUST reply with SpiceLinkAuthMechanism
C: SpiceLinkAuthMechanism (with a matching CAP_AUTH)
- SPICE_COMMON_CAP_AUTH_SPICE, the following steps and authentication
mechanism are the same as with version 2.0: a RSA_public_encrypt()
of the password is sent.
This mechanism MUST be implemented in both client and server to
comply with the SPICE protocol.
- SPICE_COMMON_CAP_AUTH_SASL, the authentication exchange follows
SASL protocol has defined in RFC 2222.
This mechanism is OPTIONAL in both client and servers.
Ex: AUTH selection, followed by SASL authentication
AUTH Selection:
C: SpiceLinkMess, CAP_PROTOCOL_AUTH_SELECTION + CAP_AUTH_SASL in common caps
S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION + CAP_AUTH_SASL in common caps
- The client MUST reply with SpiceLinkAuthMechanism
C: SpiceLinkAuthMechanism CAP_AUTH_SASL
Init:
S: u32 mechlist-length
u8-array mechlist-string
Start:
C: u32 mechname-length
u8-array mechname-string
u32 clientout-length
u8-array clientout-string
S: u32 serverin-length
u8-array serverin-string
u8 continue
Step: (while continue)
C: u32 clientout-length
u8-array clientout-string
S: u32 serverin-length
u8-array serverin-string
u8 continue
See also VNC SASL protocol description, which uses the same protocol:
http://sourceforge.net/mailarchive/forum.php?thread_name=20100719125155.GA14166%40evileye.atkac.brq.redhat.com&forum_name=tigervnc-rfbproto
Updated since v1 of this commit:
- renamed s/SPICE_CHANNEL_CAP/SPICE_COMMON_CAP
- added some note about mandatory vs optional mechanisms.
Current version 2.0 of the SPICE protocol describes how the client
reply to the server SpiceLinkReply message with a RSA_public_encrypt()
of the password.
Instead of using the current Spice AUTH mechanism, we would like to
offer different AUTH mechanisms, in particular SASL, which is a
framework allowing different underlying mechanisms such as
GSSAPI/Kerberos v5 (and optionally adding a data security layer).
We could bump the protocol version, but that would make this feature
mandatory for the implementer of the protocol. By using the channel
caps, the client and server are left to negotiate and alter the AUTH
part of the protocol as follows:
- SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION, if set, the authentication
mechanism can be chosen during link phase. If both client and server
have this cap, the client MUST reply to SpiceLinkReply with a
SpiceLinkAuthMechanism message, with the value of the CAP_AUTH
mechanism choosen (a uint32 auth_mechanism). The following
authentication steps are described by the selected authentication
mechanism.
The differents mechanisms selectable via
SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION are also specified as part of
the common channel caps. They can be used only if both client and
server offer them.
Ex: no AUTH selection
C: SpiceLinkMess
S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION not in common caps
- The client can't choose AUTH, and fallback on Spice RSA mechanism
Ex: AUTH selection
C: SpiceLinkMess, CAP_PROTOCOL_AUTH_SELECTION in common caps
S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION in common caps
- The client MUST reply with SpiceLinkAuthMechanism
C: SpiceLinkAuthMechanism (with a matching CAP_AUTH)
- SPICE_COMMON_CAP_AUTH_SPICE, the following steps and authentication
mechanism are the same as with version 2.0: a RSA_public_encrypt()
of the password is sent.
This mechanism MUST be implemented in both client and server to
comply with the SPICE protocol.
- SPICE_COMMON_CAP_AUTH_SASL, the authentication exchange follows
SASL protocol has defined in RFC 2222.
This mechanism is OPTIONAL in both client and servers.
Ex: AUTH selection, followed by SASL authentication
AUTH Selection:
C: SpiceLinkMess, CAP_PROTOCOL_AUTH_SELECTION + CAP_AUTH_SASL in common caps
S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION + CAP_AUTH_SASL in common caps
- The client MUST reply with SpiceLinkAuthMechanism
C: SpiceLinkAuthMechanism CAP_AUTH_SASL
Init:
S: u32 mechlist-length
u8-array mechlist-string
Start:
C: u32 mechname-length
u8-array mechname-string
u32 clientout-length
u8-array clientout-string
S: u32 serverin-length
u8-array serverin-string
u8 continue
Step: (while continue)
C: u32 clientout-length
u8-array clientout-string
S: u32 serverin-length
u8-array serverin-string
u8 continue
See also VNC SASL protocol description, which uses the same protocol:
http://sourceforge.net/mailarchive/forum.php?thread_name=20100719125155.GA14166%40evileye.atkac.brq.redhat.com&forum_name=tigervnc-rfbproto
Updated since v1 of this commit:
- renamed s/SPICE_CHANNEL_CAP/SPICE_COMMON_CAP
- added some note about mandatory vs optional mechanisms.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Ex: G_STRUCT_OFFSET(SpiceLinkReply, num_channel_caps) is 172 bytes
when compiled with -mms-bitfield, and 170 bytes without.
GLib/Gtk are compiled with -mms-bitfield, and it is necessary to
compile with the same option for compatibility. The pack pragma
for MINGW32 corrects the structure alignement.
We could use the pack pragma for GNUC unconditionally, that could help
to ensure struct binary compatibility between different compiled
flavours.
We are making all text send over the controller socket utf-8, rather then
having somethings as 8 bit (hostname) and others unicode16.
Adjust the CONTROLLER_MENU_*_DELIMITER defines for this.
This way the grabbing side can indicate when the clipboard owning app
can provide the clipboard contents in multiple formats, ie plain text
and html.
Also drop the VD_AGENT_CLIPBOARD_BITMAP type until we have a clear
cross platform definition of the contents to send for bitmap type
clipboard data.
-VD_AGENT_CLIPBOARD_GRAB(type) - tell the other side that an application in our side ("we") got ownership of the clipboard.
-VD_AGENT_CLIPBOARD_REQUEST(type) - after we know the other side owns the clipboard (GRAB received), we notify the os we are the owner. when we are asked by the os/app for the clipboard data, we send this REQUEST msg to the other side.
-VD_AGENT_CLIPBOARD(type, data) - the existing message for sending the clipboard, is now sent only in response to REQUEST.
-VD_AGENT_CLIPBOARD_RELEASE - tell the other side that we are no longer the owner of the clipboard (e.g. the owner app was closed).
this patch will be followed by agent & client patches handling the above messages.
spice 0.6 uses 32bpp values unconditionally for brush and palette
colors.
spice 0.4 used to use 16 bpp or 32 bpp depending on the video mode.
The qxl parser needs to know the guest video mode depth to correctly
interpret these values in spice 0.4 compat mode. Add a flag to pass
on this informartion.
Also, this changes the SpiceImage types to be more useful
as internal types, with real typed pointers. It also
adds a SpiceChunk iovec type for easy representation of
chunked data.
Clip by path has not been supported since the pixman change, and
the win32 drivers were neutered to never produce it a while ago. Also,
even before that neutering it happened extremely seldom (never seen in
real life).
We want to make these structures internal so we're free to change them.
The actual on-network ABI is now defined by the spice protocol
description rather than the c structures anyway.
Add SET_MODE IO port back in.
Add QXLRom offset fields back in.
I/O ports, RAM and ROM layout are binary compatible now.
With these changes merged it should be possible to create *one* qxl
device which supports *both* 0.4 and unstable spice commands.
Everything the guest touches before entering native mode is binary
compatible. Old (0.4) guests drivers enter native mode via SET_MODE,
new (unstqable) guest drivers enter native mode using CREATE_PRIMARY,
so when we see spice commands from the guest come in we know
whenever we have to interpret them as 0.4 or unstable ones.
Added commends to structs which need care wrt. compatibility when
updating.
Added some QXLCompat* structs for the 0.4 struct versions.
Added a flags field to QXLCommandEx so qxl can signal whenever commands
are compat or not.
Moved QXLRom->n_surfaces to make QXLRom->flags 64bit aligned.
Add padding to QXLRom to ensure future elements are 32bit aligned.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
We will switch back to 0x101 when things settle down and we guarantee
backwards compatibility. For now we will keep breaking it, bumping
revision each time this happens.
protocol commands to create/destroy surface on the client.
i removed spice_msg_display_mode as it now not needed
Signed-off-by: Izik Eidus <ieidus@redhat.com>
There is some confusion in the different branches on what the minors
mean. We expect minor == 2 to mean support for
SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST and SpiceMsgMainMigrationBegin
with added public key info. All other additions like tunneling are
for minor 3 (although we might not do a release with minor 3, but
rather the bump major).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
