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.
