spice-common.git, branch master

Cap logging level to the valid bounds

2016-03-11T10:16:22+00:00

Avoid overflows using its values.
The patch was originally written by Christophe Fergeau

Acked-by: Victor Toso

Remove 2 unused vfuncs from client_marshallers.h

2016-03-11T08:55:09+00:00

The AudioVolume and AudioMute messages are not sent by the client, so
they do not need to appear in SpiceMessageMarshallers in
client_marshallers.h

protocol: Add support for the VP8 and h264 video codecs

2016-03-10T15:59:18+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 

(cherry picked from spice-protocol commit 7937915d67702a5c4b5147b277c432f5555e3852)

Signed-off-by: Marc-André Lureau

protocol: add unix GL scanout messages

2016-03-10T15:01:46+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 

(cherry picked from spice-protocol commit 3fc2221e965623c5a7e50d95f1623269a067c2d3)

Signed-off-by: Marc-André Lureau

proto: Use proper type for preferred_compression field

2016-03-10T15:01:46+00:00

No need to use an uint8 typed member, we can directly use the
appropriate enum8 type here, which makes everything more explicit.

(cherry picked from spice-protocol commit 8a3def14e35039753097094ba356e85e8fc2d128)

Signed-off-by: Marc-André Lureau

proto: Rename image_compress to image_compression

2016-03-10T15:01:46+00:00

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.

(cherry picked from spice-protocol commit e857cd9a378cdf56805b64284491a12af93a7cbf)

Signed-off-by: Marc-André Lureau

codegen: simplify FdType

2016-03-10T15:01:42+00:00

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

(cherry picked from spice-protocol commit 47076559628d71c128e14e11147ce36b92677885)

Signed-off-by: Marc-André Lureau

protocol: learn to describe fd passing in messages

2016-03-10T15:01:42+00:00

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

(cherry-picked from spice-protocol commit 267391c8fd7c90c067b3e4845ff0227a2580e2e2)

Signed-off-by: Marc-André Lureau

Revert "Remove files moved to spice-protocol"

2016-03-10T15:01:36+00:00

This reverts commit 7665dcf1bb2fa0b16b3d0015b28d7f5912664c3f.

Also revert the related build-sys changes to fix the build.

codegen generated code depends on spice-common code (marshaller,
messages etc), it makes more sense to keep the generator along
this. Otherwise a newer protocol release will fail to build older
projects.

*.proto files are required as well, since it generates code that parent
modules depend on unconditionnaly.

Signed-off-by: Marc-André Lureau

test-logging: unset G_MESSAGES_DEBUG

2016-03-10T14:47:39+00:00

This test is sensitive to G_MESSAGES_DEBUG variable. Make it insensitive
by unsetting the environment variable.

Signed-off-by: Marc-André Lureau 
Acked-by: Frediano Ziglio