spice-protocol.git/spice, branch master

Remove codegen

2016-03-10T15:57:08+00:00

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

protocol: Add support for the VP8 and h264 video codecs

2016-03-03T17:04:44+00:00

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 
Acked-by: Christophe Fergeau

macros: do not use more type safe CONTAINEROF version if not requested

2016-03-02T12:05:55+00:00

This prevents incompatibility if users (like old spice-server/spice-gtk)
are not expected to have this additional restriction.

Signed-off-by: Frediano Ziglio 
Acked-by: Christophe Fergeau

protocol: add unix GL scanout messages

2016-01-14T11:52:41+00:00

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 
Acked-by: Frediano Ziglio

Use gcc builtin rather than asm for memory barriers

2016-01-08T14:31:38+00:00

This should make things more portable.

On my machine, __sync_synchronize() uses mfence rather than lock; addl;
Looking at the kernel memory barriers, this should be fine:
http://lxr.free-electrons.com/source/arch/x86/um/asm/barrier.h

The kernel favours using mfence, but falls back to lock; addl; when it's
not available (32 bit non-SSE machines).

https://bugs.freedesktop.org/show_bug.cgi?id=86997

macros: make SPICE_CONTAINEROF more typesafe

2015-12-04T11:15:12+00:00

Check the pointer given is the same type as member pointer.

Signed-off-by: Frediano Ziglio 
Acked-by: Jonathon Jongsma

macros: fix compatibility with non-clang compilers

2015-08-20T10:16:31+00:00

Signed-off-by: Frediano Ziglio

macros: fix alignment issue reported by clang

2015-08-20T10:05:19+00:00

char_device.c:131:52: warning: cast from 'uint8_t *'
(aka 'unsigned char *') to 'SpiceCharDeviceMsgToClientItem *'
(aka 'struct SpiceCharDeviceMsgToClientItem *')
increases required alignment from 1 to 8 [-Wcast-align]

 SpiceCharDeviceMsgToClientItem *msg_item = SPICE_CONTAINEROF(item,
                                            ^~~~~~~~~~~~~~~~~~~~~~~

../spice-common/spice-protocol/spice/macros.h:142:6: note: expanded
from macro 'SPICE_CONTAINEROF'

 ((struct_type *)((uint8_t *)(ptr) - SPICE_OFFSETOF(struct_type, member)))
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

macros: verify if __alloc_size__ works with clang

2015-08-20T10:00:35+00:00

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)))
                                                    ^

Fix endianess compatibility with old GCC versions

2015-08-19T14:42:10+00:00

GCC 4.4.7 does not define __BYTE_ORDER__ macros so use architecture
macro to attempt to detect endianess.

Signed-off-by: Frediano Ziglio 
Reported-by: Swapna Krishnan 
Tested-by: Swapna Krishnan 
Acked-by: Uri Lublin