summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2011-05-30QXL_IO_ABOUT_TO_SLEEP out valuesHEADs3.wipAlon Levy1-0/+6
2011-05-22add io ports for sleep (S3) supportAlon Levy1-0/+3
related RHBZ: 688883 Sleep is supported by the following flow: (G stands for Guest, D is the device, not the driver) G: QXL_IO_ABOUT_TO_SLEEP G: acpi reset D: qxl_reset_handler (ignored) G: QXL_IO_RETURNED_FROM_SLEEP Thereby the spice-server and the driver never reset during sleep. After an ABOUT there are three options: RETURNED - normal case vga io port written to - we already handle this by doing a qxl_soft_reset QXL_IO_RESET - we call qxl_hard_reset which calls qxl_soft_reset So to handle the two unmatched cases we just need to make sure qxl_soft_reset forgets the "ABOUT_TO_SLEEP".
2011-05-12macros: define INLINEmasterArnon 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 SpiceBitmapFmtfor_xorgAlon 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.
2010-10-25smartcard: add channelAlon Levy1-0/+13
2010-10-21controller: Make all text utf-8Hans de Goede1-2/+2
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.
2010-10-18Release 0.6.30.6.3Hans de Goede2-1/+10
2010-10-18Add controller protocolArnon Gilboa2-0/+116
2010-10-18Add foreign menu protocolArnon Gilboa2-0/+108
2010-10-12Add clipboard data types for imagesHans de Goede1-0/+4
2010-10-04VD_AGENT_CLIPBOARD_GRAB takes a list of types rather then a single typeHans de Goede1-2/+1
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.
2010-10-04vd_agent: add VD_AGENT_CAP_CLIPBOARD_BY_DEMAND capability enumArnon Gilboa1-1/+3
VD_AGENT_CLIPBOARD_NONE for unsupported clipboard types
2010-10-04vd_agent: add protocol messages for clipboard/selection-owner modelArnon Gilboa1-1/+12
-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.
2010-09-29Bump version to 0.6.10.6.1Alexander Larsson1-1/+1
2010-09-29Update for releaseAlexander Larsson1-0/+4
2010-09-14add compat flag for 16bpp modeGerd Hoffmann1-1/+2
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.
2010-08-31Bump version to 0.6.00.6.0Alexander Larsson1-2/+2
2010-08-31Update NEWS for releaseAlexander Larsson1-0/+6
2010-08-31add vd_agent announce capabilities messageAlon Levy1-0/+28
2010-08-30Merge commit 'e27cb334cf70409c7e32be6f061921b4b317be17'Alon Levy1-0/+12
2010-08-30move pipe header defines from reds.c to spice-protocolAlon Levy1-0/+10
2010-08-29Update NEWS for releaseAlexander Larsson1-0/+9
2010-08-29Update version to 0.5.3Alexander Larsson1-1/+1
2010-08-29Change major to 2 to declare network protocol stableAlexander Larsson1-1/+1
2010-08-29vdagent protocol: add display settingYonit Halperin1-0/+13
2010-07-21client/agent: add clipboard max size limit for sending to/from the guest agentArnon Gilboa1-0/+2
define default & env variable for overriding it
2010-07-20Update NEWS for release0.5.3Alexander Larsson1-0/+9
2010-07-20Update version to 0.5.3Alexander Larsson1-1/+1
2010-07-20Change major to 2 to declare network protocol stableAlexander Larsson1-1/+1
2010-07-19vdagent protocol: add display settingYonit Halperin1-0/+13
2010-07-11clipboard agent message addedAlon Levy1-0/+13
2010-07-08Update NEWS for release0.5.2Alexander Larsson1-0/+7
2010-07-08Fix misspellingsAlexander Larsson3-9/+9
SpicedSubMessage -> SpiceSubMessage QXLAlphaBlnd -> QXLAlphaBlend
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-16 02:35:53 +0000