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.
