This message is a replacement for the original gl scanout
message which does not support multi plane and modifier.
Signed-off-by: Qiang Yu <yuq825@gmail.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>
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>
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>
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>
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>
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.
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)
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 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
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.
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.
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..
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.
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.
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).
