summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-06-15Add an 8BIT_A formata8Søren Sandmann Pedersen1-0/+1
This format corresponds to a sequence of bytes, each of which represents an alpha value.
2012-05-11Add QXL_ESCAPE_SET_CUSTOM_DISPLAYMarc-André Lureau2-0/+21
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);
2012-05-08Release 0.10.3Alon Levy2-1/+10
2012-04-24video streaming: add support for frames of different sizesYonit Halperin2-0/+5
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.
2012-04-09qxl_dev: fix const cast warning for QXL_R[AO]M_MAGICAlon Levy1-2/+2
2012-04-03Add controller messages for USB redirectionChristophe Fergeau1-0/+4
This adds 3 new controller messages: CONTROLLER_ENABLE_USB (ControllerValue, boolean) CONTROLLER_ENABLE_USB_AUTOSHARE (ControllerValue, boolean) CONTROLLER_USB_FILTER (ControllerData, string) This fixes rhbz #807295
2012-04-03Fix typo in commentChristophe Fergeau1-1/+1
2012-04-02controller: add COLOR_DEPTH and DISABLE_EFFECTS messagesYonit Halperin1-0/+3
rhbz #787447 Signed-off-by: Yonit Halperin <yhalperi@redhat.com>
2012-03-19build-sys: use git.mkMarc-André Lureau5-36/+252
2012-03-05Add name & uuid messages on main channelMarc-André Lureau2-0/+3
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.
2012-02-23build: include spice/types.h in foreign_menu_prot.hMarc-André Lureau1-0/+1
The header uses some types only defined in stdint.h. Apparently, the rest of the headers include types.h for that.
2012-02-22build: clean up build to not be dirty after autogenMarc-André Lureau2-1/+2
2012-02-17Add controller message ENABLE_SMARTCARDMarc-André Lureau2-1/+3
The sent message must be a ControllerValue whose value is either '0' disabled, or '1' enabled.
2012-01-12Release 0.10.1Yonit Halperin2-1/+5
2012-01-12Add support for mini header: an header without sub list & without serialYonit Halperin1-1/+7
-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.
2012-01-12enums.h: add SPICE_MSG_LISTYonit Halperin1-3/+2
- 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
2012-01-08Fix SPICE_STAT_SHM_NAME to be portableNahum Shalman1-1/+1
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.
2011-11-10Release 0.10.0Alon Levy2-2/+6
2011-11-10autogen.sh: handle ORIGDIR with spacesAlon Levy1-1/+1
2011-10-02Release 0.9.1Yonit Halperin4-2/+12
Cherry-pick of abfdf4d8abf95d003678af5df814f3b1be1fd092 (Release 0.8.2) semi-seamless migration RHBZ 738262 Conflicts: NEWS configure.ac
2011-08-25Release 0.9.0Hans de Goede2-2/+7
2011-08-25NEWS: sync with 0.8 branchHans de Goede1-0/+25
2011-08-25Change usbredir messages to spicevmc messagesHans de Goede1-5/+7
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>
2011-08-13Add definitions and enums for usbredir channelHans de Goede1-0/+13
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2011-07-17bump version to 0.8.1 for qxl_dev.h changesAlon Levy1-1/+1
2011-07-17qxl_dev: add third revision V10Alon Levy1-2/+6
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.
2011-07-17qxl_dev: add QXL_INTERRUPT_ERRORAlon Levy1-0/+1
The interrupt is used to notify the guest driver it did an error in the last io operation. It can be left unhandled.
2011-07-17add QXL_IO_FLUSH_{SURFACES,RELEASE} for sleep (S3) supportAlon Levy1-0/+2
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.
2011-07-17Add async I/O commands.Gerd Hoffmann1-0/+8
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>
2011-06-22protocol: add SPICE_{PLAYBACK,RECORD}_CAP_VOLUME capsMarc-André Lureau1-0/+2
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..
2011-06-22spice: enums.h regeneratedMarc-André Lureau1-70/+75
2011-05-12macros: define INLINEArnon Gilboa1-0/+6
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.
2011-04-18protocol: set version number to 0.8.0Christophe Fergeau1-2/+2
spice-protocol 0.8.0 has been released, but for some reason the version number in the master branch was still at 0.6.3
2011-04-11protocol: use packed-start/end to pack structuresChristophe Fergeau2-25/+17
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.
2011-04-11controller: add missing spice/types includeMarc-André Lureau1-0/+2
2011-03-24vd_agent.h: Add a VDP_END_PORT to the chunk port enumHans de Goede1-0/+1
2011-03-07qxl_dev: introduce defines for rings sizesAlon Levy1-3/+7
2011-03-03Merge branch 'master' of git://git.freedesktop.org/git/spice/spice-protocolAlon Levy1-0/+26
2011-02-28protocol: add clipboard selection capabilityMarc-André Lureau1-0/+26
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/ClipboardsWiki https://bugs.freedesktop.org/show_bug.cgi?id=34833
2011-02-23protocol: add common channel caps for AUTH mechanism selectionMarc-André Lureau1-0/+10
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.
2011-02-23protocol: add common channel caps for AUTH mechanism selectionMarc-André Lureau1-0/+10
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>
2011-02-10enums: typedefy SpiceBitmapFmtAlon Levy1-2/+2
2011-02-10qxl_dev.h: make QXLEffectType an enum instead of definesAlon Levy1-8/+11
2011-02-10qxl_dev.h: make QXLBitmapFlags a typedefAlon Levy1-2/+2
2011-02-10qxl_dev.h: make QXLSurfaceCmdType a typedefAlon Levy1-2/+2
2011-02-10qxl_dev.h: name QXL_IMAGE_* flags as type and enum QXLImageFlagsAlon Levy1-2/+2
2011-02-10qxl_dev.h: make QXLCmdType enum also a typedefAlon Levy1-2/+2
2011-02-02define spice_mb MemoryBarrier for WIN64Arnon Gilboa1-0/+9
__asm is not supported on _WIN64, so use macro instead required for Windows x64 guest display driver (qxldd.dll)
2011-01-21Update license header for spice/macros.hHans de Goede1-6/+6
This one mistakenly had a GPL header rather then an LGPL header.
2010-12-29mingw32: specify packing alignment to 1 byte, to override -mms-bitfieldMarc-André Lureau2-3/+5
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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-15 21:40:18 +0000