Re: [Spice-devel] GStreamer's zero-copy code is broken

[Francois Gouget]

On Thu, 2 Mar 2017, Frediano Ziglio wrote:
[...]
> Before I forgot this.
> 
> Looks like GStreamer when you call gst_buffer_add_video_meta_full
> assume that buffer is contiguous. The 8 pixel shift (more or less)
> you can see are artifacts due to how the guest send the frames but
> basically are bytes inside 2 chunks of data.
> 
> Problems happens specifically in gst_video_frame_map_id.

Did you report this bug to GStreamer?
If not it would be nice if you could dump your current understanding 
into a bug for future reference.


> (passing metadata is also required to pass texture directly to VAAPI).

Interesting. Does it need the same type of GstVideoMeta data or some 
other type of metadata?

Did you get the pipeline to work with VAAPI?

-- 
Francois Gouget 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] KVM-SPICE: View youtube videos smoothly

[Oscar Segarra]

Hi,

In my environment I have a W10 guest running on a centos 7 KVM host.

I have installed the following QXL Video driver:

[image: Imágenes integradas 1]

But when I try to see (on LAN) a youtube video, it doesn't play smoothly,
even video and sound stops for a while and continues a little bit later. It
looks I can see the video rendering as i can see a the half of one frame
and the half of the following frame on the same "image".

If I minimize the internet explorer (or chrome) to the task-bar image and
sound goes better (not the perfect).

¿Is there any advice to improve video and sound experience in KVM with
spice?

Thanks a lot,
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH v2 2/2] display-channel: Handle timeout for joining drawables

[Jonathon Jongsma]

I'm trying to decide if there's any benefit to splitting this out from
the other patch. I'm leaning toward squashing them.

On Thu, 2017-03-02 at 11:34 +, Frediano Ziglio wrote:
> The previous patch join correctly the commands however if there
> are no more commands the command joined is delayed till new
> commands arrive. This patch introduce a timeout (currently 10 ms)
> after the command is executed.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/display-channel-private.h |  4 -
>  server/display-channel.c | 36 
> -
>  2 files changed, 31 insertions(+), 9 deletions(-)
> 
> diff --git a/server/display-channel-private.h b/server/display-
> channel-private.h
> index 62e03b6..e289e45 100644
> --- a/server/display-channel-private.h
> +++ b/server/display-channel-private.h
> @@ -20,6 +20,8 @@
>  
>  #include "display-channel.h"
>  
> +#define JOINABLE_TIMEOUT 10 // ms
> +
>  #define NUM_DRAWABLES 1000
>  typedef struct _Drawable _Drawable;
>  struct _Drawable {
> @@ -69,6 +71,8 @@ struct DisplayChannelPrivate
>  
>  int gl_draw_async_count;
>  
> +uint32_t joinable_generation;
> +SpiceTimer *joinable_timeout;
>  RedDrawable *joinable_drawable;
>  
>  /* TODO: some day unify this, make it more runtime.. */
> diff --git a/server/display-channel.c b/server/display-channel.c
> index 37d1703..8993b12 100644
> --- a/server/display-channel.c
> +++ b/server/display-channel.c
> @@ -78,6 +78,9 @@ display_channel_finalize(GObject *object)
>  {
>  DisplayChannel *self = DISPLAY_CHANNEL(object);
>  
> +SpiceCoreInterfaceInternal* core =
> red_channel_get_core_interface(RED_CHANNEL(self));
> +core->timer_remove(core, self->priv->joinable_timeout);
> +
>  display_channel_destroy_surfaces(self);
>  image_cache_reset(&self->priv->image_cache);
>  monitors_config_unref(self->priv->monitors_config);
> @@ -1330,17 +1333,23 @@
> display_channel_process_draw_single(DisplayChannel *display,
> RedDrawable *red_dr
>  drawable_unref(drawable);
>  }
>  
> +static void display_joinable_timeout(void *opaque)
> +{
> +DisplayChannel *display = opaque;
> +if (display->priv->joinable_drawable) {
> +display_channel_process_draw_single(display, display->priv-
> >joinable_drawable,
> +display->priv-
> >joinable_generation);
> +red_drawable_unref(display->priv->joinable_drawable);
> +display->priv->joinable_drawable = NULL;
> +}
> +}
> +
>  void display_channel_process_draw(DisplayChannel *display,
> RedDrawable *red_drawable,
>    uint32_t
> process_commands_generation)
>  {
>  if (!red_drawable_joinable(red_drawable)) {
>  // not joinable, process all
> -if (display->priv->joinable_drawable) {
> -display_channel_process_draw_single(display, display-
> >priv->joinable_drawable,
> -process_commands_gen
> eration);
> -red_drawable_unref(display->priv->joinable_drawable);
> -display->priv->joinable_drawable = NULL;
> -}
> +display_joinable_timeout(display);

Here I see that my comment on the previous patch (about
process_commands_generation) is no longer an issue because it's now
saved and used in display_joinable_timeout()

>  display_channel_process_draw_single(display, red_drawable,
> process_commands_generation);
>  return;
>  }
> @@ -1351,12 +1360,15 @@ void
> display_channel_process_draw(DisplayChannel *display, RedDrawable
> *red_draw
>  red_drawable = red_drawable_join(display->priv-
> >joinable_drawable, red_drawable);
>  } else {
>  // they can't be joined
> -display_channel_process_draw_single(display, display->priv-
> >joinable_drawable,
> -process_commands_generat
> ion);
> -red_drawable_unref(display->priv->joinable_drawable);
> +display_joinable_timeout(display);
>  }
> +
>  // try to join with next one
>  red_drawable_ref(red_drawable);
> +
> +SpiceCoreInterfaceInternal* core =
> red_channel_get_core_interface(RED_CHANNEL(display));
> +core->timer_start(core, display->priv->joinable_timeout,
> JOINABLE_TIMEOUT);
> +display->priv->joinable_generation =
> process_commands_generation;
>  display->priv->joinable_drawable = red_drawable;
>  }
>  
> @@ -2227,6 +2239,12 @@ display_channel_constructed(GObject *object)
>  self->priv->stream_video = SPICE_STREAM_VIDEO_OFF;
>  display_channel_init_streams(self);
>  
> +SpiceCoreInterfaceInternal* core =
> red_channel_get_core_interface(channel);
> +self->priv->joinable_timeout = core->timer_add(core,
> display_joinable_timeout, self);
> +if (!self->priv->joinable_timeout) {
> +spice_error("joinable timer create failed");
> +}
> +
>  red_channel_set_cap(channel, SPICE_DISPLAY_CAP_MONITORS_CONFIG);
>  

Re: [Spice-devel] [PATCH v2 1/2] display-channel: Join drawables to improve rhel7 behaviour

[Jonathon Jongsma]

On Thu, 2017-03-02 at 11:34 +, Frediano Ziglio wrote:
> Due to the way RHEL7 works the images came out from guest using
> multiple
> commands. This increase the commands to the client and cause the
> video code to create and handle multiple streams creating some
> visual glitches.
> This patch attempt to detect and join the multiple commands to
> avoid these issues.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/display-channel-private.h |   2 +-
>  server/display-channel.c | 173
> +++-
>  server/red-parse-qxl.h   |   1 +-
>  server/red-worker.c  |  14 +--
>  4 files changed, 183 insertions(+), 7 deletions(-)
> 
> diff --git a/server/display-channel-private.h b/server/display-
> channel-private.h
> index da807d1..62e03b6 100644
> --- a/server/display-channel-private.h
> +++ b/server/display-channel-private.h
> @@ -69,6 +69,8 @@ struct DisplayChannelPrivate
>  
>  int gl_draw_async_count;
>  
> +RedDrawable *joinable_drawable;
> +
>  /* TODO: some day unify this, make it more runtime.. */
>  stat_info_t add_stat;
>  stat_info_t exclude_stat;
> diff --git a/server/display-channel.c b/server/display-channel.c
> index fa2b281..37d1703 100644
> --- a/server/display-channel.c
> +++ b/server/display-channel.c
> @@ -1175,8 +1175,147 @@ static void
> display_channel_add_drawable(DisplayChannel *display, Drawable *draw
>  #endif
>  }
>  
> -void display_channel_process_draw(DisplayChannel *display,
> RedDrawable *red_drawable,
> -  uint32_t
> process_commands_generation)
> +/* Check that a given drawable it's a simple copy that can be

- it's -> is
- remove the extra 'be' at the end of the line above

> + * possibly be joined to next one.
> + * This is used to undo some engine which split images into
> + * chunks causing more commands and creating multiple streams.
> + * One example is RHEL 7.

maybe reword this:

"This is used to work around some drivers which split larger image
updates into smaller chunks. These chunks are generally horizontal
strips. This can cause our stream-detection heuristics to generate
multiple streams instead of a single stream, and results in more
commands being sent to the client."

> + */
> +static gboolean red_drawable_joinable(const RedDrawable *drawable)
> +{
> +/* these 3 initial tests are arranged to minimize checks as
> + * they are in reverse order of occurrences */

"reverse order of occurrence" implies to me that the first one is the
least likely to occur. Is that what you intended? I think it should be
the opposite, right?

(also: occurrences should just be occurrence (singular))

> +if (drawable->clip.type != SPICE_CLIP_TYPE_NONE) {
> +return FALSE;
> +}
> +if (drawable->type != QXL_DRAW_COPY) {
> +return FALSE;
> +}
> +if (drawable->effect != QXL_EFFECT_OPAQUE) {
> +return FALSE;
> +}
> +if (drawable->self_bitmap) {
> +return FALSE;
> +}
> +if (drawable->surface_deps[0] != -1 ||
> +drawable->surface_deps[1] != -1 ||
> +drawable->surface_deps[2] != -1) {
> +return FALSE;
> +}
> +
> +const SpiceCopy *copy = &drawable->u.copy;
> +if (copy->src_bitmap == NULL) {
> +return FALSE;
> +}
> +if (copy->rop_descriptor != SPICE_ROPD_OP_PUT) {
> +return FALSE;
> +}
> +if (copy->mask.bitmap != NULL) {
> +return FALSE;
> +}
> +
> +const SpiceImage *image = copy->src_bitmap;
> +if (image->descriptor.type != SPICE_IMAGE_TYPE_BITMAP) {
> +return FALSE;
> +}
> +const SpiceBitmap *bitmap = &image->u.bitmap;
> +if (bitmap->format != SPICE_BITMAP_FMT_RGBA && bitmap->format !=
> SPICE_BITMAP_FMT_32BIT) {
> +return FALSE;
> +}
> +if (bitmap->flags != SPICE_BITMAP_FLAGS_TOP_DOWN) {
> +return FALSE;
> +}
> +if (bitmap->palette != NULL) {
> +return FALSE;
> +}
> +if (bitmap->data == NULL) {
> +return FALSE;
> +}
> +if (bitmap->data->flags & SPICE_CHUNKS_FLAGS_UNSTABLE) {
> +return FALSE;
> +}
> +if (bitmap->x != image->descriptor.width ||
> +bitmap->y != image->descriptor.height) {
> +return FALSE;
> +}
> +/* area should specify all image */
> +if (copy->src_area.left != 0 || copy->src_area.top != 0 ||
> +copy->src_area.right != bitmap->x || copy->src_area.bottom
> != bitmap->y) {
> +return FALSE;
> +}
> +if (drawable->bbox.right - drawable->bbox.left != bitmap->x ||
> +drawable->bbox.bottom - drawable->bbox.top != bitmap->y) {
> +return FALSE;
> +}

It's not really clear to me why all of these checks are necessary, or
whether there are any checks missing. How did you decide which checks
were required? Can any comments be added?


> +
> +return TRUE;
> +}
> +
> +static gboolean red_drawable_can_join(const RedDrawable *first,
> const RedDrawable *second)
> 

Re: [Spice-devel] [PATCH v2 0/2] RHEL7 improvements

[Jonathon Jongsma]

On Thu, 2017-03-02 at 11:34 +, Frediano Ziglio wrote:
> These 2 patches attempt to join images split by RHEL7 graphic
> stack (Mesa) decreasing commands handled by spice-server.
> 
> You can see the difference between the 2 video:
> - https://www.youtube.com/watch?v=OarV6zUmUdg (before)
> - https://www.youtube.com/watch?v=5fTdCCbFeCg (after)
> These video are realized with some additional changes:
> - the statistics from the terminal have some additional
>   "out_messages" counters. These counters show the messages
>   sent to the client(s). These changes are part of my "stat"
>   branch (partially sent couple of days ago);
> - the replay utility, as you can see, was changed to replay
>   using the real time to allow the video code (which is dependent
>   on timing) to work correctly. The patch is currently not in
>   a good shape (enough to be sent);
> - the client utility was changed to remove the delay due to
>   the lip sync. The glitches (present mostly before these patches)
>   are much reduced.
> 
> Note the number of commands sent to the client reduced from 6097
> to 2016 (current year, just a coincidence).
> The network traffic reduced from 72M to 56M. This is due to the fact
> that having a single stream (as you can see VP8 codec was used) the
> compression on the stream is better.
> 
> These patches fix:
> - https://bugzilla.redhat.com/show_bug.cgi?id=1158029;
> - (probably) https://bugzilla.redhat.com/show_bug.cgi?id=1294564.
> 
> Changes since RFC:
> - moved code to DisplayChannel;
> - define a constant for timeout.
> 
> Future possible optimization: not waiting to join if the joined
> command end at the screen bottom or if the last command contain
> a small image (Mesa split at about 64K pixel, 256Kb).
> 
> In some experiments with the modified replay utility I got
> some additional artifacts respect to the RFC version. This is mainly
> due to the way RedWorker handle commands from graphic driver and the
> way the timeout was handled. In the previous version before checking
> for joining timeout the graphic command queue were always checked
> while with this last series is possible that the timeout trigger
> before checking for new command. This however seems to happen mainly
> to me as the replay utility introduce some delay.

To expand on this a little bit for posterity:

Without these patches, The driver on RHEL7 splits updates up into
separate drawable commands that are thin horizontal strips instead of
updating the entire area at once. Our stream-detection heuristics treat
these as multiple separate streams instead of one single larger stream.
For example:

+-+
| |
|  +-+|
|  | Stream A||
|  +-+|
|  | Stream B||
|  +-+|
|  | Stream C||
|  +-+|
| |
| |
+-+

There are several problems with this. As mentioned above, it generates
extra commands to transfer to the client. And since these strips are
not perfectly synchronized, it can create visual glitches or "tearing"
of the video.

These patches attempt to delay processing of certain drawable commands
for a short time so that we can compare one command to the next command
to see if they are directly on top of eachother. If they are, then we
join them and wait to see if the next command can also be joined. We
keep joining commands this until we recieve a command that cannot be
joined, at which point we process the joined command. Then we start the
process again.

When these commands are joined successfully, our stream-detection
heuristics work as they did in previous versions of linux and we
generate a single stream for the entire updated area:

+-+
| |
|  +-+|
|  | ||
|  | ||
|  | Stream A||
|  | ||
|  | ||
|  +-+|
| |
| |
+-+


The second patch attempts to solve the situation where there are no
more drawable updates after we recieve the final joinable drawable
command? We could be waiting for the next non-joinable drawable forever
and never process the delayed commands. So it adds a timeout to process
these delayed commands if this situation occurs. But what value do we
use for the timeout? If we choose a too-long timeout, it increases
latency. If we choose a too-short timeout, it increases the chance that
we may process the delayed commands when there are still joinable
comm

[Spice-devel] [PATCH spice-server] Revert "gstreamer: Avoid memory copy if strides are different"

[Frediano Ziglio]

This reverts commit c3d237075b994fe67e58f2b3164cb579e6f4.
---
 server/gstreamer-encoder.c | 26 ++
 1 file changed, 6 insertions(+), 20 deletions(-)

diff --git a/server/gstreamer-encoder.c b/server/gstreamer-encoder.c
index 991eb51..df54cad 100644
--- a/server/gstreamer-encoder.c
+++ b/server/gstreamer-encoder.c
@@ -1236,6 +1236,8 @@ static void clear_zero_copy_queue(SpiceGstEncoder 
*encoder, gboolean unref_queue
 /* Nothing to do */
 }
 
+#endif
+
 /* A helper for push_raw_frame() */
 static inline int line_copy(SpiceGstEncoder *encoder, const SpiceBitmap 
*bitmap,
 uint32_t chunk_offset, uint32_t stream_stride,
@@ -1266,8 +1268,6 @@ static inline int line_copy(SpiceGstEncoder *encoder, 
const SpiceBitmap *bitmap,
  return TRUE;
 }
 
-#endif
-
 /* A helper for push_raw_frame() */
 static inline int chunk_copy(SpiceGstEncoder *encoder, const SpiceBitmap 
*bitmap,
  uint32_t chunk_index, uint32_t chunk_offset,
@@ -1350,8 +1350,8 @@ static int push_raw_frame(SpiceGstEncoder *encoder,
   gpointer bitmap_opaque)
 {
 uint32_t height = src->bottom - src->top;
-uint32_t len;
-uint32_t chunk_index = 0;
+uint32_t stream_stride = (src->right - src->left) * encoder->format->bpp / 
8;
+uint32_t len = stream_stride * height;
 GstBuffer *buffer = gst_buffer_new();
 /* TODO Use GST_MAP_INFO_INIT once GStreamer 1.4.5 is no longer relevant */
 GstMapInfo map = { .memory = NULL };
@@ -1362,10 +1362,6 @@ static int push_raw_frame(SpiceGstEncoder *encoder,
 uint32_t skip_lines = top_down ? src->top : bitmap->y - (src->bottom - 0);
 uint32_t chunk_offset = bitmap->stride * skip_lines;
 
-#ifndef DO_ZERO_COPY
-uint32_t stream_stride = (src->right - src->left) * encoder->format->bpp / 
8;
-
-len = stream_stride * height;
 if (stream_stride != bitmap->stride) {
 /* We have to do a line-by-line copy because for each we have to
  * leave out pixels on the left or right.
@@ -1381,19 +1377,9 @@ static int push_raw_frame(SpiceGstEncoder *encoder,
 return VIDEO_ENCODER_FRAME_UNSUPPORTED;
 }
 } else {
-#else
-{
-/* using GStreamer 1.0, we can avoid cropping the image by simply 
passing
- * the appropriate offset and stride as metadata */
-gsize offset[] = { src->left * encoder->format->bpp / 8 };
-gint stride[] = { bitmap->stride };
-gst_buffer_add_video_meta_full(buffer, GST_VIDEO_FRAME_FLAG_NONE,
-   encoder->format->gst_format, bitmap->x, 
bitmap->y,
-   1, offset, stride);
-
-len = bitmap->stride * height;
-
 /* We can copy the bitmap chunk by chunk */
+uint32_t chunk_index = 0;
+#ifdef DO_ZERO_COPY
 if (!zero_copy(encoder, bitmap, bitmap_opaque, buffer, &chunk_index,
&chunk_offset, &len)) {
 gst_buffer_unref(buffer);
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [RFC spice-gtk 3/3] just disable usbredir compression

[Snir Sheriber]

---
 src/channel-usbredir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/channel-usbredir.c b/src/channel-usbredir.c
index fef62ce..318adf1 100644
--- a/src/channel-usbredir.c
+++ b/src/channel-usbredir.c
@@ -282,7 +282,7 @@ void 
spice_usbredir_channel_set_context(SpiceUsbredirChannel *channel,
 usbredirhost_set_buffered_output_size_cb(priv->host, 
usbredir_buffered_output_size_callback);
 #endif
 #ifdef USE_LZ4
-spice_channel_set_capability(channel, 
SPICE_SPICEVMC_CAP_DATA_COMPRESS_LZ4);
+//spice_channel_set_capability(channel, 
SPICE_SPICEVMC_CAP_DATA_COMPRESS_LZ4);
 #endif
 }
 
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [RFC spice-common] Adding compressed message to base channel

[Snir Sheriber]

---
 spice.proto | 4 
 1 file changed, 4 insertions(+)

diff --git a/spice.proto b/spice.proto
index e841272..3cad253 100644
--- a/spice.proto
+++ b/spice.proto
@@ -188,6 +188,8 @@ channel BaseChannel {
 
 Data list; /* the msg body is SpiceSubMessageList */
 
+CompressedData compressed_data;
+
 Empty base_last = 100;
 
  client:
@@ -210,6 +212,8 @@ channel BaseChannel {
uint64 time_stamp;
link_err reason;
 } @ctype(SpiceMsgDisconnect) disconnecting;
+
+CompressedData compressed_data;
 };
 
 struct ChannelId {
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [RFC protocol 2/2] Adding LZ4 compression common caps and LZ4 stream type

[Snir Sheriber]

Assuming LZ4 capabilities could handle both LZ4 stream message
and regular LZ4 compressed message
---
 spice/enums.h| 1 +
 spice/protocol.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/spice/enums.h b/spice/enums.h
index a931497..136813c 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -124,6 +124,7 @@ typedef enum SpicePubkeyType {
 typedef enum SpiceDataCompressionType {
 SPICE_DATA_COMPRESSION_TYPE_NONE,
 SPICE_DATA_COMPRESSION_TYPE_LZ4,
+SPICE_DATA_COMPRESSION_TYPE_STREAM_LZ4,
 
 SPICE_DATA_COMPRESSION_TYPE_ENUM_END
 } SpiceDataCompressionType;
diff --git a/spice/protocol.h b/spice/protocol.h
index cbf2f01..9831ee5 100644
--- a/spice/protocol.h
+++ b/spice/protocol.h
@@ -57,6 +57,7 @@ enum {
 SPICE_COMMON_CAP_AUTH_SPICE,
 SPICE_COMMON_CAP_AUTH_SASL,
 SPICE_COMMON_CAP_MINI_HEADER,
+SPICE_COMMON_CAP_LZ4_COMPRESSION,
 };
 
 typedef struct SPICE_ATTR_PACKED SpiceLinkMess {
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [RFC spice-gtk 2/3] Sending LZ4 compressed msgs over selected channels

[Snir Sheriber]

If channel number is included in the CHANNEL_COMPRESS environment
variable, LZ4 compression will be applied on the channel messages
if possible.

First LZ4 stream compression is trying to be applied, if message
size is too large, regular LZ4 compression is applied, in stream
compression mode messages are being saved sequentially in pre-allocated
buffer which will be utilized by the compression mechanism in the
following compressions
---
 src/spice-channel-priv.h |   4 ++
 src/spice-channel.c  | 163 ++-
 2 files changed, 165 insertions(+), 2 deletions(-)

diff --git a/src/spice-channel-priv.h b/src/spice-channel-priv.h
index 2eaf816..6315626 100644
--- a/src/spice-channel-priv.h
+++ b/src/spice-channel-priv.h
@@ -110,6 +110,10 @@ struct _SpiceChannelPrivate {
 LZ4_streamDecode_t  *lz4_in_stream;
 char*in_stream_buf;
 size_t  in_stream_offset;
+
+LZ4_stream_t*lz4_out_stream;
+char*out_stream_buf;
+size_t  out_stream_offset;
 #endif
 
 /* not swapped */
diff --git a/src/spice-channel.c b/src/spice-channel.c
index 5f07bd6..8e83f70 100644
--- a/src/spice-channel.c
+++ b/src/spice-channel.c
@@ -143,6 +143,39 @@ static void spice_channel_init(SpiceChannel *channel)
 g_mutex_init(&c->xmit_queue_lock);
 }
 
+#ifdef USE_LZ4
+static bool spice_channel_asked_for_compression(SpiceChannel *channel)
+{
+/*
+ * Check if current channel was included by the user in
+ * the COMPRESS_CHANNELS environment variable. The format
+ * to ask for specific channel compression is as follows:
+ * COMPRESS_CHANNELS=,,<...
+ */
+const char* pChannels;
+
+pChannels = g_getenv("COMPRESS_CHANNELS");
+if (pChannels != NULL) {
+SpiceChannelPrivate *c;
+char **result = NULL;
+int i = 0;
+
+c = channel->priv = SPICE_CHANNEL_GET_PRIVATE(channel);
+result = g_strsplit_set(pChannels,",.:;-",-1);
+
+while (result[i] != NULL) {
+if (c->channel_type == atoi(result[i])) {
+g_strfreev(result);
+return true;
+}
+i++;
+}
+g_strfreev(result);
+}
+return false;
+}
+#endif
+
 static void spice_channel_constructed(GObject *gobject)
 {
 SpiceChannel *channel = SPICE_CHANNEL(gobject);
@@ -161,6 +194,13 @@ static void spice_channel_constructed(GObject *gobject)
 c->lz4_in_stream = LZ4_createStreamDecode();
 c->in_stream_buf = g_malloc(STREAM_BUF_SIZE);
 c->in_stream_offset = 0;
+
+if(spice_channel_asked_for_compression(channel) && 
g_socket_get_family(c->sock) != G_SOCKET_FAMILY_UNIX) {
+spice_channel_set_common_capability(channel, 
SPICE_COMMON_CAP_LZ4_COMPRESSION);
+c->lz4_out_stream = LZ4_createStream();
+c->out_stream_buf = g_malloc(STREAM_BUF_SIZE);
+c->out_stream_offset = 0;
+}
 #endif
 spice_session_channel_new(c->session, channel);
 
@@ -203,6 +243,11 @@ static void spice_channel_finalize(GObject *gobject)
 LZ4_freeStreamDecode(c->lz4_in_stream);
 
 g_free(c->in_stream_buf);
+
+if(c->lz4_out_stream)
+LZ4_freeStream(c->lz4_out_stream);
+
+g_free(c->out_stream_buf);
 #endif
 
 if (c->caps)
@@ -902,6 +947,113 @@ static void spice_channel_write(SpiceChannel *channel, 
const void *data, size_t
 spice_channel_flush_wire(channel, data, len);
 }
 
+#ifdef USE_LZ4
+static char* out_stream_get_ptr(SpiceChannel *channel) {
+
+SpiceChannelPrivate *c;
+
+c = SPICE_CHANNEL(channel)->priv;
+
+return &c->out_stream_buf[c->out_stream_offset];
+
+}
+
+static void out_stream_update(SpiceChannel *channel, int size)
+{
+SpiceChannelPrivate *c;
+
+c = SPICE_CHANNEL(channel)->priv;
+/* Add size to the stream buffer offset & reset if needed
+ * so that place for new message is always available */
+c->out_stream_offset += size;
+if (c->out_stream_offset >= STREAM_BUF_SIZE - COMPRESS_STREAM_MAX_MSG_SIZE)
+c->out_stream_offset = 0;
+}
+
+static LZ4_stream_t* out_stream_get_stream(SpiceChannel *channel)
+{
+SpiceChannelPrivate *c;
+
+c = SPICE_CHANNEL(channel)->priv;
+
+return c->lz4_out_stream;
+}
+
+static int spice_channel_try_write_compressed_msg(SpiceChannel *channel, 
uint8_t *data, int count)
+{
+SpiceMsgOut *msg_out_compressed;
+int bound, compressed_data_count;
+uint8_t type;
+char *compressed_buf;
+
+if (out_stream_get_stream(channel) == NULL) {
+/* Allocation failed or capability is disabled */
+return FALSE;
+}
+if (!spice_channel_test_common_capability(channel, 
SPICE_COMMON_CAP_LZ4_COMPRESSION)) {
+/* Server doesn't support stream compression in this channel */
+return FALSE;
+}
+if (count < COMPRESS_STREAM_MIN_THRESHOLD) {
+/* Not worth compression */
+return FALSE;
+  

[Spice-devel] [RFC protocol 1/2] Adding compressed data message to base channel

[Snir Sheriber]

---
 spice/enums.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/spice/enums.h b/spice/enums.h
index 0074b0f..a931497 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -436,6 +436,7 @@ enum {
 SPICE_MSG_DISCONNECTING,
 SPICE_MSG_NOTIFY,
 SPICE_MSG_LIST,
+SPICE_MSG_COMPRESSED_DATA,
 SPICE_MSG_BASE_LAST = 100,
 };
 
@@ -446,6 +447,7 @@ enum {
 SPICE_MSGC_MIGRATE_FLUSH_MARK,
 SPICE_MSGC_MIGRATE_DATA,
 SPICE_MSGC_DISCONNECTING,
+SPICE_MSGC_COMPRESSED_DATA,
 };
 
 enum {
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [RFC server 1/3] Handle LZ4 compressed messages in rcc

[Snir Sheriber]

If LZ4 lib exists, handle LZ4 compressed & stream compressed
messages in any channel

In stream compression mode decompressed messages are being saved
sequentially in a pre-allocated buffer which will be utilized
by the decompression mechanism in the following decompressions

Update spice-common
---
 server/red-channel-client.c | 128 
 spice-common|   2 +-
 2 files changed, 129 insertions(+), 1 deletion(-)

diff --git a/server/red-channel-client.c b/server/red-channel-client.c
index cd4b64e..600a9f2 100644
--- a/server/red-channel-client.c
+++ b/server/red-channel-client.c
@@ -31,6 +31,9 @@
 #ifdef HAVE_LINUX_SOCKIOS_H
 #include  /* SIOCOUTQ */
 #endif
+#ifdef USE_LZ4
+#include 
+#endif
 #include 
 
 #include "red-channel-client.h"
@@ -99,6 +102,11 @@ typedef struct IncomingMessageBuffer {
 uint32_t header_pos;
 uint8_t *msg; // data of the msg following the header. allocated by 
alloc_msg_buf.
 uint32_t msg_pos;
+#ifdef USE_LZ4
+LZ4_streamDecode_t *lz4StreamDecode;
+char *stream_buf;
+size_t stream_offset;
+#endif
 } IncomingMessageBuffer;
 
 struct RedChannelClientPrivate
@@ -209,6 +217,14 @@ enum ConnectivityState {
 CONNECTIVITY_STATE_DISCONNECTED,
 };
 
+#ifdef USE_LZ4
+enum {
+COMPRESS_STREAM_MIN_THRESHOLD = 6,
+COMPRESS_STREAM_MAX_MSG_SIZE = 1024 * 64, /* Maximum message size for LZ4 
stream compression */
+STREAM_BUF_SIZE = 1024 * 64 + COMPRESS_STREAM_MAX_MSG_SIZE + 8 /* 
Recommended buffer size according to the api */
+};
+#endif
+
 typedef struct RedEmptyMsgPipeItem {
 RedPipeItem base;
 int msg;
@@ -365,6 +381,13 @@ red_channel_client_finalize(GObject *object)
 
 reds_stream_free(self->priv->stream);
 self->priv->stream = NULL;
+#ifdef USE_LZ4
+if (self->priv->incoming.lz4StreamDecode) {
+LZ4_freeStreamDecode(self->priv->incoming.lz4StreamDecode);
+}
+
+free(self->priv->incoming.stream_buf);
+#endif
 
 if (self->priv->send_data.main.marshaller) {
 spice_marshaller_destroy(self->priv->send_data.main.marshaller);
@@ -404,6 +427,11 @@ static void red_channel_client_constructed(GObject *object)
 self->priv->is_mini_header = FALSE;
 }
 self->priv->incoming.header.data = self->priv->incoming.header_buf;
+#ifdef USE_LZ4
+self->priv->incoming.lz4StreamDecode = LZ4_createStreamDecode();
+self->priv->incoming.stream_buf = spice_malloc(STREAM_BUF_SIZE);
+self->priv->incoming.stream_offset = 0;
+#endif
 }
 
 static void red_channel_client_class_init(RedChannelClientClass *klass)
@@ -1233,6 +1261,94 @@ static uint8_t 
*red_channel_client_parse(RedChannelClient *rcc, uint8_t *message
 return parsed_message;
 }
 
+#ifdef USE_LZ4
+static char* in_stream_get_ptr(IncomingMessageBuffer *buffer)
+{
+if (buffer->stream_buf) {
+return &buffer->stream_buf[buffer->stream_offset];
+} else {
+return NULL;
+}
+}
+
+static void in_stream_update(IncomingMessageBuffer *buffer, int size)
+{
+/* Add size to the stream buffer offset & reset if needed so that
+ * place for new message is always available */
+buffer->stream_offset += size;
+if (buffer->stream_offset >= STREAM_BUF_SIZE - 
COMPRESS_STREAM_MAX_MSG_SIZE) {
+buffer->stream_offset = 0;
+}
+}
+
+#endif
+
+static int red_channel_client_handle_compressed_msg(RedChannelClient *rcc,
+SpiceMsgCompressedData 
*compressed_data_msg)
+{
+IncomingMessageBuffer *buffer = &rcc->priv->incoming;
+int decompressed_size;
+uint32_t msg_size;
+uint16_t msg_type;
+char *decompressed = NULL;
+
+switch (compressed_data_msg->type) {
+#ifdef USE_LZ4
+case SPICE_DATA_COMPRESSION_TYPE_STREAM_LZ4: {
+if (!(decompressed = in_stream_get_ptr(buffer))) {
+return FALSE;
+}
+decompressed_size = 
LZ4_decompress_safe_continue(buffer->lz4StreamDecode,
+ (char 
*)compressed_data_msg->compressed_data,
+ decompressed,
+ 
compressed_data_msg->compressed_size,
+ 
compressed_data_msg->uncompressed_size);
+break;
+}
+case SPICE_DATA_COMPRESSION_TYPE_LZ4: {
+if (!(decompressed = 
spice_malloc(compressed_data_msg->uncompressed_size))) {
+return FALSE;
+}
+decompressed_size = LZ4_decompress_safe((char 
*)compressed_data_msg->compressed_data,
+decompressed,
+
compressed_data_msg->compressed_size,
+
compressed_data_msg->uncompressed_size);
+break;
+}
+#endif
+default:
+spice_warning("Invalid Compression Type");
+return FALSE;
+

[Spice-devel] [RFC spice-gtk 1/3] Handle LZ4 compressed msgs in any channel

[Snir Sheriber]

If LZ4 lib exists, handle LZ4 compressed & stream compressed
messages in any channel

In stream compression mode decompressed messages are being saved
sequentially in a pre-allocated buffer which will be utilized
by the decompression mechanism in the following decompressions

Update spice-common
---
 spice-common |   2 +-
 src/spice-channel-priv.h |  12 
 src/spice-channel.c  | 150 +++
 3 files changed, 163 insertions(+), 1 deletion(-)

diff --git a/spice-common b/spice-common
index 30e8237..cde4a8b 16
--- a/spice-common
+++ b/spice-common
@@ -1 +1 @@
-Subproject commit 30e8237934b4060513bd0bdcc5ea0caa1dcc7b59
+Subproject commit cde4a8bb67330006ee26e1c0d5892c824edce327
diff --git a/src/spice-channel-priv.h b/src/spice-channel-priv.h
index 50aca5c..2eaf816 100644
--- a/src/spice-channel-priv.h
+++ b/src/spice-channel-priv.h
@@ -27,6 +27,10 @@
 #include 
 #endif
 
+#ifdef USE_LZ4
+#include
+#endif
+
 #include "spice-channel.h"
 #include "spice-util-priv.h"
 #include "coroutine.h"
@@ -62,6 +66,8 @@ struct _SpiceMsgIn {
 size_tpsize;
 message_destructor_t  pfree;
 SpiceMsgIn*parent;
+bool  stream_buf_in_use;
+uint8_t   header_offset;
 };
 
 enum spice_channel_state {
@@ -100,6 +106,12 @@ struct _SpiceChannelPrivate {
 uint64_tout_serial;
 uint64_tin_serial;
 
+#ifdef USE_LZ4
+LZ4_streamDecode_t  *lz4_in_stream;
+char*in_stream_buf;
+size_t  in_stream_offset;
+#endif
+
 /* not swapped */
 SpiceSession*session;
 GCoroutine  coroutine;
diff --git a/src/spice-channel.c b/src/spice-channel.c
index af67931..5f07bd6 100644
--- a/src/spice-channel.c
+++ b/src/spice-channel.c
@@ -47,6 +47,14 @@
 
 #include "gio-coroutine.h"
 
+#ifdef USE_LZ4
+enum {
+COMPRESS_STREAM_MIN_THRESHOLD = 6,
+COMPRESS_STREAM_MAX_MSG_SIZE = 1024 * 64, /* Maximum message size for LZ4 
stream compression */
+STREAM_BUF_SIZE = 1024 *64 + COMPRESS_STREAM_MAX_MSG_SIZE + 8 /* 
Recommended buffer size according to the api */
+};
+#endif
+
 static void spice_channel_handle_msg(SpiceChannel *channel, SpiceMsgIn *msg);
 static void spice_channel_write_msg(SpiceChannel *channel, SpiceMsgOut *out);
 static void spice_channel_send_link(SpiceChannel *channel);
@@ -149,6 +157,11 @@ static void spice_channel_constructed(GObject *gobject)
 if (disabled && strstr(disabled, desc))
 c->disable_channel_msg = TRUE;
 
+#ifdef USE_LZ4
+c->lz4_in_stream = LZ4_createStreamDecode();
+c->in_stream_buf = g_malloc(STREAM_BUF_SIZE);
+c->in_stream_offset = 0;
+#endif
 spice_session_channel_new(c->session, channel);
 
 /* Chain up to the parent class */
@@ -185,6 +198,13 @@ static void spice_channel_finalize(GObject *gobject)
 
 g_mutex_clear(&c->xmit_queue_lock);
 
+#ifdef USE_LZ4
+if(c->lz4_in_stream)
+LZ4_freeStreamDecode(c->lz4_in_stream);
+
+g_free(c->in_stream_buf);
+#endif
+
 if (c->caps)
 g_array_free(c->caps, TRUE);
 
@@ -504,6 +524,10 @@ SpiceMsgIn *spice_msg_in_new(SpiceChannel *channel)
 in = g_new0(SpiceMsgIn, 1);
 in->refcount = 1;
 in->channel  = channel;
+#ifdef USE_LZ4
+in->stream_buf_in_use = FALSE;
+in->header_offset = 0;
+#endif
 
 return in;
 }
@@ -546,7 +570,15 @@ void spice_msg_in_unref(SpiceMsgIn *in)
 in->pfree(in->parsed);
 if (in->parent) {
 spice_msg_in_unref(in->parent);
+#ifdef USE_LZ4
+} else if(in->header_offset > 0) {
+   /* points to the allocated buffer in header_offset offset */
+   g_free(in->data - in->header_offset);
+} else if(!in->stream_buf_in_use) {
+   /* points to the stream buffer */
+#else
 } else {
+#endif
 g_free(in->data);
 }
 g_free(in);
@@ -1939,6 +1971,119 @@ gboolean spice_channel_get_read_only(SpiceChannel 
*channel)
 return spice_session_get_read_only(channel->priv->session);
 }
 
+#ifdef USE_LZ4
+static char* in_stream_get_ptr(SpiceChannel *channel)
+{
+SpiceChannelPrivate *c;
+
+c = SPICE_CHANNEL(channel)->priv;
+
+return &c->in_stream_buf[c->in_stream_offset];
+
+}
+
+static void in_stream_update(SpiceChannel *channel, int size)
+{
+SpiceChannelPrivate *c;
+
+c = SPICE_CHANNEL(channel)->priv;
+/* Add size to the stream buffer offset & reset if needed
+ * so that place for new message is always available */
+c->in_stream_offset += size;
+if (c->in_stream_offset >= STREAM_BUF_SIZE - COMPRESS_STREAM_MAX_MSG_SIZE)
+c->in_stream_offset = 0;
+}
+
+static LZ4_streamDecode_t* in_stream_get_stream(SpiceChannel *channel)
+{
+SpiceChannelPrivate *c;
+
+c = SPICE_CHANNEL(channel)->priv;
+
+return c->lz4_in_stream;
+}
+#endif
+
+static int spice_channel_recv_compressed_msg(SpiceChannel *channel,
+

[Spice-devel] [RFC server 3/3] just disable usbredir compression

[Snir Sheriber]

---
 server/spicevmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/server/spicevmc.c b/server/spicevmc.c
index abb0b52..074a8cf 100644
--- a/server/spicevmc.c
+++ b/server/spicevmc.c
@@ -207,7 +207,7 @@ red_vmc_channel_constructed(GObject *object)
 stat_init_counter(&self->out_uncompressed, reds, stat, "out_uncompressed", 
TRUE);
 
 #ifdef USE_LZ4
-red_channel_set_cap(RED_CHANNEL(self), 
SPICE_SPICEVMC_CAP_DATA_COMPRESS_LZ4);
+//red_channel_set_cap(RED_CHANNEL(self), 
SPICE_SPICEVMC_CAP_DATA_COMPRESS_LZ4);
 #endif
 
 red_channel_init_outgoing_messages_window(RED_CHANNEL(self));
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [RFC server 2/3] Sending LZ4 compressed msgs over selected channels

[Snir Sheriber]

If channel number is included in the CHANNEL_COMPRESS environment
variable, LZ4 compression will be applied on the channel messages
if possible.

First LZ4 stream compression is trying to be applied, if message
size is too large, regular LZ4 compression is applied, in stream
compression mode messages are being saved sequentially in pre-allocated
buffer which will be utilized by the compression mechanism in the
following compressions
---
 server/red-channel-client.c | 147 
 server/red-channel.c|  35 +++
 2 files changed, 182 insertions(+)

diff --git a/server/red-channel-client.c b/server/red-channel-client.c
index 600a9f2..8655ced 100644
--- a/server/red-channel-client.c
+++ b/server/red-channel-client.c
@@ -94,6 +94,11 @@ typedef struct OutgoingMessageBuffer {
 int vec_size;
 int pos;
 int size;
+#ifdef USE_LZ4
+LZ4_stream_t *lz4Stream;
+char *stream_buf;
+size_t stream_offset;
+#endif
 } OutgoingMessageBuffer;
 
 typedef struct IncomingMessageBuffer {
@@ -164,6 +169,10 @@ static void 
red_channel_client_clear_sent_item(RedChannelClient *rcc);
 static void red_channel_client_destroy_remote_caps(RedChannelClient* rcc);
 static void red_channel_client_initable_interface_init(GInitableIface *iface);
 static void red_channel_client_set_message_serial(RedChannelClient *channel, 
uint64_t);
+#ifdef USE_LZ4
+static int red_channel_client_test_local_common_cap(RedChannelClient *rcc, 
uint32_t cap);
+#endif
+
 
 /*
  * When an error occurs over a channel, we treat it as a warning
@@ -387,6 +396,12 @@ red_channel_client_finalize(GObject *object)
 }
 
 free(self->priv->incoming.stream_buf);
+
+if(self->priv->outgoing.lz4Stream) {
+LZ4_freeStream(self->priv->outgoing.lz4Stream);
+}
+
+free(self->priv->outgoing.stream_buf);
 #endif
 
 if (self->priv->send_data.main.marshaller) {
@@ -431,6 +446,12 @@ static void red_channel_client_constructed(GObject *object)
 self->priv->incoming.lz4StreamDecode = LZ4_createStreamDecode();
 self->priv->incoming.stream_buf = spice_malloc(STREAM_BUF_SIZE);
 self->priv->incoming.stream_offset = 0;
+if (red_channel_client_test_local_common_cap(self, 
SPICE_COMMON_CAP_LZ4_COMPRESSION) &&
+reds_stream_get_family(red_channel_client_get_stream(self)) != 
AF_UNIX) {
+self->priv->outgoing.lz4Stream = LZ4_createStream();
+self->priv->outgoing.stream_buf = spice_malloc(STREAM_BUF_SIZE);
+self->priv->outgoing.stream_offset = 0;
+}
 #endif
 }
 
@@ -738,6 +759,16 @@ static void 
red_channel_client_destroy_remote_caps(RedChannelClient* rcc)
 free(rcc->priv->remote_caps.caps);
 }
 
+#ifdef USE_LZ4
+static int red_channel_client_test_local_common_cap(RedChannelClient *rcc, 
uint32_t cap)
+{
+RedChannel *channel = red_channel_client_get_channel(rcc);
+const RedChannelCapabilities *caps = 
red_channel_get_local_capabilities(channel);
+
+return test_capability(caps->common_caps, caps->num_common_caps, cap);
+}
+#endif
+
 int red_channel_client_test_remote_common_cap(RedChannelClient *rcc, uint32_t 
cap)
 {
 return test_capability(rcc->priv->remote_caps.common_caps,
@@ -1155,6 +1186,119 @@ static void 
red_channel_client_release_msg_buf(RedChannelClient *rcc,
 klass->release_recv_buf(rcc, type, size, msg);
 }
 
+#ifdef USE_LZ4
+static char* out_stream_get_ptr(OutgoingMessageBuffer *buffer)
+{
+if(buffer->stream_buf)
+return &buffer->stream_buf[buffer->stream_offset];
+else
+return NULL;
+}
+
+static void out_stream_update(OutgoingMessageBuffer *buffer, int size)
+{
+/* Add size to the stream buffer offset & reset if needed
+ * so that place for new message is always available */
+buffer->stream_offset += size;
+if ((size_t)buffer->stream_offset >= STREAM_BUF_SIZE - 
COMPRESS_STREAM_MAX_MSG_SIZE)
+buffer->stream_offset = 0;
+}
+
+/* Getting current message from the marshaller, linearize it, try to
+ * compress it and if compression is successful marshall the compressed
+ * message instead of the original one */
+static int red_channel_client_try_to_compress(RedChannelClient *rcc)
+{
+uint8_t *data, type;
+char *compressed_buf, *uncompressed_buf;
+int  free_data;
+size_t len;
+int compressed_data_count;
+int bound;
+OutgoingMessageBuffer *buffer = &rcc->priv->outgoing;
+
+if(buffer->stream_buf == NULL) {
+/* Allocation failed or capability is disabled */
+return FALSE;
+}
+if(!red_channel_client_test_remote_common_cap(rcc, 
SPICE_COMMON_CAP_LZ4_COMPRESSION)) {
+/* Client doesn't support stream compression at this channel */
+return FALSE;
+}
+if (buffer->size < COMPRESS_STREAM_MIN_THRESHOLD) {
+/* size < threshold - data will not be compressed */
+return FALSE;
+}
+
+data = spice_marshaller_linearize(rcc->priv->send_data.marshaller, 0, 
&len, &free_data);
+bound = LZ

[Spice-devel] [RFC] Spice channels compression

[Snir Sheriber]

This series of patches allows compression of messages over
selected spice channels

Few notes:

*Currently lz4 stream and regular compression are in use for small and large
messages accordingly. packets are being sent in common msg type that was added,
and it utilize previous compressed message structure.

*The stream compression & decompression dictionary is based on previous 
messages,
there for messages that has compressed\decompressed in stream mode are being 
saved
in continuous pre-allocated buffer and a pointer is used for tracking current
position.

*Currently all channels are allowed to be compressed, we might want to avoid
compression for some channels (for good or just in specific cases) ***please
notice that usbredir compression was not revert yet so meanwhile i added 2 small
patches to disable its compression caps.

*Multiple clients- basically it should work with more than one client, although 
adding
compression/decompression to just part of the clients could theoretically make 
it
worse (good for compression performance testing though)

-If someone has encountered issues with the combination of compression and 
other spice features please let me know
-Suggestions and comments are welcome, especially for improving the messages 
sending  :)

Snir.

Spice components:
server,client,spice-common,spice-protocol

-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] GStreamer's zero-copy code is broken

[Frediano Ziglio]

> 
> On Fri, 24 Feb 2017, Francois Gouget wrote:
> 
> > On Fri, 24 Feb 2017, Christophe de Dinechin wrote:
> > [...]
> > > Looking at the patch, I wonder why we pass an offset and a stride from
> > > different sources (offset is from the source, but stride is from the
> > > bitmap)? Shouldn’t we use the stream stride?
> > 
> > I think that's correct:
> >  * bitmap->{x,y} are the width and height of the source image.
> > 
> >  * bitmap->stride is the size in bytes of each line. In other words
> >that's how much you must add to the pointer to get the pixel of the
> >next line.
> > 
> >  * src->{left,right,top,bottom} identifies which subset of the source
> >image should be encoded and sent to the client. So the offset
> >corresponds to the src->left.
> > 
> > However I don't see any way to tell gst_buffer_add_video_meta_full()
> > that you only want to take 400 pixels out of every 640 pixel line, or
> > only 200 lines out of the 480 lines.
> > 
> > For instance if we have
> >   bitmap->x = 640
> >   bitmap->y = 480
> >   bitmap->stride = 2560
> >   src->left = src->top = 0
> >   src->right = 200
> >   src->bottom = 100
> > 
> > Then we will call:
> > 
> > gst_buffer_add_video_meta_full(buffer, GST_VIDEO_FRAME_FLAG_NONE,
> > encoder->format->gst_format,
> > 640 /* bitmap->x */, 480 /* bitmap->y */,
> > 1,
> > { 0 } /* offset */,
> > { 2560 } /* stride */);
> > 
> > How will GStreamer know that it should encode a 200x100 video since we
> > did not tell it that:
> > src->right - src->left = 200
> > src>bottom - src->top = 100
> 
> Actually the GStreamer pipeline 'knows' the size of the area to encode
> through the source caps which are then (if I remember correctly)
> attached to the buffer.
> 
> Also src->top is taken into account through the chunk_offset value which
> is the offset in bytes into the bitmap data computed by zero_copy().
> 

Before I forgot this.

Looks like GStreamer when you call gst_buffer_add_video_meta_full
assume that buffer is contiguous. The 8 pixel shift (more or less)
you can see are artifacts due to how the guest send the frames but
basically are bytes inside 2 chunks of data.

Problems happens specifically in gst_video_frame_map_id.

I would revert the patch for the time being adding this call later
in case we have only one chunks (passing metadata is also required
to pass texture directly to VAAPI).

Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] How to send a custom resolution message to windows/linux guest vdagent

[Thiago Nascimento Araujo]

Hi,

First of all, thank you all for the quick answers.

The cut off message was my fault, sorry about that.

I am trying to understand this:

Lets say I am connected to a win/lnx guest though remote-viewer and my 
remote-viewer is a window with the dimensions 1440x900, so:

When I resize the window from 1440x900 to 1024x768 (manually resize the 
remote-viewer window, not the screen resolution inside the guest), what is the 
process involved from the remote-viewer to communicate to the guest (with 
spice-guest-tools installed) to peform the guest resize ?

Is something like:
a) remote-viewer inform his new resolution sending a message ?
b) the agents capture this message ?
c) the agents set the new resolution inside the client ?

I want to understand how "arbitrary resolution" are possible.
I can't create an arbitrary resolution using the win-api, for example, all I 
can do is search for the available modes starting the devnode using enumdisplay 
from win-api. But using remote-viewer I can force a 672x350 resolution for 
example.

So, why I need this?

I am trying to create a way to grab a window resolution (the windows explorer 
at 700x500 window resolution, for example) and set the win guest screen 
resolution to match the same resolution of the explorer. Wrapping the 
remote-viewer window around the explorer and adapt when is needed.

I am implementing a VDi solution that works like a "terminal service app".

An user wants to use a notepad, for example, then I created a program that 
resides inside the win guest, that receives the desired app and hides 
everything else (desktop, taskbar, start menu, blocks win-menu and other keys 
bindings) and only present the user with notepad. (There's a similar solution 
for lnx as well in progress)

So far, everything is ok for win/lnx (most of it) guests - the only thing I 
can't do, is set arbitrary resolutions, specially on windows guests.

So I thought: I have to find a way to grab the notepad resolution (that part is 
done) and send it to the spice-channel and create the "wrapping effect around 
notepad".

Thank you all in advance.

PS: sorry about my english - still learning.


- Mensagem original -
De: "Jonathon Jongsma" 
Para: "Thiago Nascimento Araujo" , 
spice-devel@lists.freedesktop.org
Enviadas: Quinta-feira, 2 de março de 2017 12:05:46
Assunto: Re: [Spice-devel] How to send a custom resolution message to 
windows/linux guest vdagent

On Thu, 2017-03-02 at 03:58 -0300, Thiago Nascimento Araujo wrote:
> Hello,
> 
> Is there a way to send a spice message, connect to pipe, or any other
> method to contact vdservice/vdagent to create/simulate a resize to an
> arbitrary resolution or full screen effect caused by remote-viewer?
> 
> Any other ways I can connect to the named pipes (windows guests or
> linux guests) and watch/debug/learn. I cant find or connect to the
> windows guest named pipe and I got connection refused trying to socat
> to a port in linux guest.
> 
> I really need some guidance to fully understand how arbitrary
> resolutions are created using win/lnx/spice api.
> 
> Thanks in advance.
> 
> Or a way to 
> ___

Hi Thiago,

Seems your message got cut off or something.

My main question is: what is your end goal exactly? You say you're
trying to simulate a resize and therefore you want to connect to a
named pipe to do that. But there are probably better ways to do that,
depending on your final goal. Also note that in recent linux guests,
the vdagent executable is not really involved in the resolution
changing process at all. Once we know what you're actually trying to do
it will probably be easier to help you.

Cheers,
Jonathon
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v4 3/3] red-channel: Use RedChannelCapabilities directly to pass capabilities

[Jonathon Jongsma]

Looks fine to me, with potential changes from TYPE_RED_ to RED_TYPE_
due to changes in previous patches.

Acked-by: Jonathon Jongsma 


On Thu, 2017-03-02 at 12:30 +, Frediano Ziglio wrote:
> For each channel there are two set of capabilities, one
> for the common ones and one for the specific ones.
> A single set were almost always passed using 2 arguments,
> a number of elements and an array but then before using
> these were converted to a GArray.
> Use a single structure (already available) to pass all
> channel capabilites using a single argument.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/cursor-channel-client.c| 22 ++
>  server/cursor-channel-client.h|  4 +--
>  server/cursor-channel.c   |  6 ++--
>  server/cursor-channel.h   |  3 +-
>  server/dcc.c  | 22 ++
>  server/dcc.h  |  5 +---
>  server/inputs-channel-client.c| 23 ++-
>  server/inputs-channel-client.h|  5 +---
>  server/inputs-channel.c   |  7 ++---
>  server/main-channel-client.c  | 22 ++
>  server/main-channel-client.h  |  3 +-
>  server/main-channel.c |  7 ++---
>  server/main-channel.h |  4 +--
>  server/red-channel-client.c   | 62 +--
> 
>  server/red-channel-client.h   |  3 +-
>  server/red-channel.c  | 19 
>  server/red-channel.h  |  7 ++---
>  server/red-qxl.c  | 24 ---
>  server/red-qxl.h  | 10 ++-
>  server/red-worker.c   | 11 +++
>  server/reds.c | 41 ++
>  server/smartcard-channel-client.c | 22 ++
>  server/smartcard-channel-client.h |  3 +-
>  server/smartcard.c|  6 ++--
>  server/sound.c| 37 +--
>  server/spicevmc.c | 11 ---
>  26 files changed, 94 insertions(+), 295 deletions(-)
> 
> diff --git a/server/cursor-channel-client.c b/server/cursor-channel-
> client.c
> index 56efd1e..1a05f73 100644
> --- a/server/cursor-channel-client.c
> +++ b/server/cursor-channel-client.c
> @@ -93,21 +93,9 @@ void
> cursor_channel_client_migrate(RedChannelClient *rcc)
>  
>  CursorChannelClient* cursor_channel_client_new(CursorChannel
> *cursor, RedClient *client, RedsStream *stream,
> int mig_target,
> -   uint32_t
> *common_caps, int num_common_caps,
> -   uint32_t *caps, int
> num_caps)
> +   RedChannelCapabilitie
> s *caps)
>  {
>  CursorChannelClient *rcc;
> -GArray *common_caps_array = NULL, *caps_array = NULL;
> -
> -if (common_caps) {
> -common_caps_array = g_array_sized_new(FALSE, FALSE, sizeof
> (*common_caps),
> -  num_common_caps);
> -g_array_append_vals(common_caps_array, common_caps,
> num_common_caps);
> -}
> -if (caps) {
> -caps_array = g_array_sized_new(FALSE, FALSE, sizeof (*caps),
> num_caps);
> -g_array_append_vals(caps_array, caps, num_caps);
> -}
>  
>  rcc = g_initable_new(TYPE_CURSOR_CHANNEL_CLIENT,
>   NULL, NULL,
> @@ -115,16 +103,10 @@ CursorChannelClient*
> cursor_channel_client_new(CursorChannel *cursor, RedClient
>   "client", client,
>   "stream", stream,
>   "monitor-latency", FALSE,
> - "common-caps", common_caps_array,
> - "caps", caps_array,
> + "caps", caps,
>   NULL);
>  common_graphics_channel_set_during_target_migrate(COMMON_GRAPHIC
> S_CHANNEL(cursor), mig_target);
>  
> -if (caps_array)
> -g_array_unref(caps_array);
> -if (common_caps_array)
> -g_array_unref(common_caps_array);
> -
>  return rcc;
>  }
>  
> diff --git a/server/cursor-channel-client.h b/server/cursor-channel-
> client.h
> index d1dd31d..e2aa3a8 100644
> --- a/server/cursor-channel-client.h
> +++ b/server/cursor-channel-client.h
> @@ -63,9 +63,7 @@ CursorChannelClient*
> cursor_channel_client_new(CursorChannel *cursor,
> RedClient *client,
> RedsStream *stream,
> int mig_target,
> -   uint32_t
> *common_caps,
> -   int num_common_caps,
> -   uint32_t *caps, int
> num_caps);
> +   RedChannelCapabilitie
> s *caps);
>  
>  void cursor_channel_client_reset_cursor_cache(RedChannelClient
> *rc

Re: [Spice-devel] [PATCH spice-server v2] record: Allocate recording file globally from reds.c

[Jonathon Jongsma]

Acked-by: Jonathon Jongsma 


On Thu, 2017-03-02 at 15:28 +, Frediano Ziglio wrote:
> Allows to use recording function for multiple purposes.
> This will allow to register multiple screen VM or recording
> additional stuff like sound.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/red-worker.c   |  6 +-
>  server/reds-private.h |  2 ++
>  server/reds.c | 18 ++
>  server/reds.h |  5 +
>  4 files changed, 26 insertions(+), 5 deletions(-)
> 
> Changes since v1:
> - typo;
> - free record from spice_server_destroy.
> 
> diff --git a/server/red-worker.c b/server/red-worker.c
> index 93cb615..326e775 100644
> --- a/server/red-worker.c
> +++ b/server/red-worker.c
> @@ -1312,7 +1312,6 @@ RedWorker* red_worker_new(QXLInstance *qxl,
>  QXLDevInitInfo init_info;
>  RedWorker *worker;
>  Dispatcher *dispatcher;
> -const char *record_filename;
>  RedsState *reds = red_qxl_get_server(qxl->st);
>  RedChannel *channel;
>  
> @@ -1322,10 +1321,7 @@ RedWorker* red_worker_new(QXLInstance *qxl,
>  worker->core = event_loop_core;
>  worker->core.main_context = g_main_context_new();
>  
> -record_filename = getenv("SPICE_WORKER_RECORD_FILENAME");
> -if (record_filename) {
> -worker->record = red_record_new(record_filename);
> -}
> +worker->record = reds_get_record(reds);
>  dispatcher = red_qxl_get_dispatcher(qxl);
>  dispatcher_set_opaque(dispatcher, worker);
>  
> diff --git a/server/reds-private.h b/server/reds-private.h
> index e7e9ad7..07b7b38 100644
> --- a/server/reds-private.h
> +++ b/server/reds-private.h
> @@ -25,6 +25,7 @@
>  #include "main-channel.h"
>  #include "inputs-channel.h"
>  #include "stat-file.h"
> +#include "red-record-qxl.h"
>  
>  #define MIGRATE_TIMEOUT (MSEC_PER_SEC * 10)
>  #define MM_TIME_DELTA 400 /*ms*/
> @@ -135,6 +136,7 @@ struct RedsState {
>  SpiceCoreInterfaceInternal core;
>  GList *qxl_instances;
>  MainDispatcher *main_dispatcher;
> +RedRecord *record;
>  };
>  
>  #define FOREACH_QXL_INSTANCE(_reds, _iter, _qxl) \
> diff --git a/server/reds.c b/server/reds.c
> index f99dfda..caf7f74 100644
> --- a/server/reds.c
> +++ b/server/reds.c
> @@ -3452,7 +3452,9 @@ static const char default_video_codecs[] =
> "spice:mjpeg;" GSTREAMER_CODECS;
>  /* new interface */
>  SPICE_GNUC_VISIBLE SpiceServer *spice_server_new(void)
>  {
> +const char *record_filename;
>  RedsState *reds = spice_new0(RedsState, 1);
> +
>  reds->config = spice_new0(RedServerConfig, 1);
>  reds->config->default_channel_security =
>  SPICE_CHANNEL_SECURITY_NONE | SPICE_CHANNEL_SECURITY_SSL;
> @@ -3484,6 +3486,12 @@ SPICE_GNUC_VISIBLE SpiceServer
> *spice_server_new(void)
>  reds->listen_socket = -1;
>  reds->secure_listen_socket = -1;
>  
> +/* This environment was in red-worker so the "WORKER" in it.
> + * For compatibility reason we maintain the old name */
> +record_filename = getenv("SPICE_WORKER_RECORD_FILENAME");
> +if (record_filename) {
> +reds->record = red_record_new(record_filename);
> +}
>  return reds;
>  }
>  
> @@ -3692,6 +3700,7 @@ SPICE_GNUC_VISIBLE void
> spice_server_destroy(SpiceServer *reds)
> close(reds->secure_listen_socket);
>  }
>  
> +red_record_unref(reds->record);
>  reds_cleanup(reds);
>  #ifdef RED_STATISTICS
>  stat_file_free(reds->stat_file);
> @@ -4519,3 +4528,12 @@ static RedCharDeviceVDIPort
> *red_char_device_vdi_port_new(RedsState *reds)
>  "self-tokens",
> (guint64)REDS_NUM_INTERNAL_AGENT_MESSAGES,
>  NULL);
>  }
> +
> +RedRecord *reds_get_record(RedsState *reds)
> +{
> +if (reds->record) {
> +return red_record_ref(reds->record);
> +}
> +
> +return NULL;
> +}
> diff --git a/server/reds.h b/server/reds.h
> index 28e3444..2748102 100644
> --- a/server/reds.h
> +++ b/server/reds.h
> @@ -101,6 +101,11 @@ SpiceCoreInterfaceInternal*
> reds_get_core_interface(RedsState *reds);
>  void reds_update_client_mouse_allowed(RedsState *reds);
>  MainDispatcher* reds_get_main_dispatcher(RedsState *reds);
>  
> +/* Get the recording object stored in RedsState.
> + * You should free with red_record_unref.
> + */
> +struct RedRecord *reds_get_record(RedsState *reds);
> +
>  /* fd watches/timers */
>  SpiceWatch *reds_core_watch_add(RedsState *reds,
>  int fd, int event_mask,
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v4 3/3] red-channel: Use RedChannelCapabilities directly to pass capabilities

[Frediano Ziglio]

> 
> Looks fine to me, with potential changes from TYPE_RED_ to RED_TYPE_
> due to changes in previous patches.
> 
> Acked-by: Jonathon Jongsma 
> 

Done (both)

Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server v2] record: Allocate recording file globally from reds.c

[Frediano Ziglio]

Allows to use recording function for multiple purposes.
This will allow to register multiple screen VM or recording
additional stuff like sound.

Signed-off-by: Frediano Ziglio 
---
 server/red-worker.c   |  6 +-
 server/reds-private.h |  2 ++
 server/reds.c | 18 ++
 server/reds.h |  5 +
 4 files changed, 26 insertions(+), 5 deletions(-)

Changes since v1:
- typo;
- free record from spice_server_destroy.

diff --git a/server/red-worker.c b/server/red-worker.c
index 93cb615..326e775 100644
--- a/server/red-worker.c
+++ b/server/red-worker.c
@@ -1312,7 +1312,6 @@ RedWorker* red_worker_new(QXLInstance *qxl,
 QXLDevInitInfo init_info;
 RedWorker *worker;
 Dispatcher *dispatcher;
-const char *record_filename;
 RedsState *reds = red_qxl_get_server(qxl->st);
 RedChannel *channel;
 
@@ -1322,10 +1321,7 @@ RedWorker* red_worker_new(QXLInstance *qxl,
 worker->core = event_loop_core;
 worker->core.main_context = g_main_context_new();
 
-record_filename = getenv("SPICE_WORKER_RECORD_FILENAME");
-if (record_filename) {
-worker->record = red_record_new(record_filename);
-}
+worker->record = reds_get_record(reds);
 dispatcher = red_qxl_get_dispatcher(qxl);
 dispatcher_set_opaque(dispatcher, worker);
 
diff --git a/server/reds-private.h b/server/reds-private.h
index e7e9ad7..07b7b38 100644
--- a/server/reds-private.h
+++ b/server/reds-private.h
@@ -25,6 +25,7 @@
 #include "main-channel.h"
 #include "inputs-channel.h"
 #include "stat-file.h"
+#include "red-record-qxl.h"
 
 #define MIGRATE_TIMEOUT (MSEC_PER_SEC * 10)
 #define MM_TIME_DELTA 400 /*ms*/
@@ -135,6 +136,7 @@ struct RedsState {
 SpiceCoreInterfaceInternal core;
 GList *qxl_instances;
 MainDispatcher *main_dispatcher;
+RedRecord *record;
 };
 
 #define FOREACH_QXL_INSTANCE(_reds, _iter, _qxl) \
diff --git a/server/reds.c b/server/reds.c
index f99dfda..caf7f74 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3452,7 +3452,9 @@ static const char default_video_codecs[] = "spice:mjpeg;" 
GSTREAMER_CODECS;
 /* new interface */
 SPICE_GNUC_VISIBLE SpiceServer *spice_server_new(void)
 {
+const char *record_filename;
 RedsState *reds = spice_new0(RedsState, 1);
+
 reds->config = spice_new0(RedServerConfig, 1);
 reds->config->default_channel_security =
 SPICE_CHANNEL_SECURITY_NONE | SPICE_CHANNEL_SECURITY_SSL;
@@ -3484,6 +3486,12 @@ SPICE_GNUC_VISIBLE SpiceServer *spice_server_new(void)
 reds->listen_socket = -1;
 reds->secure_listen_socket = -1;
 
+/* This environment was in red-worker so the "WORKER" in it.
+ * For compatibility reason we maintain the old name */
+record_filename = getenv("SPICE_WORKER_RECORD_FILENAME");
+if (record_filename) {
+reds->record = red_record_new(record_filename);
+}
 return reds;
 }
 
@@ -3692,6 +3700,7 @@ SPICE_GNUC_VISIBLE void spice_server_destroy(SpiceServer 
*reds)
close(reds->secure_listen_socket);
 }
 
+red_record_unref(reds->record);
 reds_cleanup(reds);
 #ifdef RED_STATISTICS
 stat_file_free(reds->stat_file);
@@ -4519,3 +4528,12 @@ static RedCharDeviceVDIPort 
*red_char_device_vdi_port_new(RedsState *reds)
 "self-tokens", 
(guint64)REDS_NUM_INTERNAL_AGENT_MESSAGES,
 NULL);
 }
+
+RedRecord *reds_get_record(RedsState *reds)
+{
+if (reds->record) {
+return red_record_ref(reds->record);
+}
+
+return NULL;
+}
diff --git a/server/reds.h b/server/reds.h
index 28e3444..2748102 100644
--- a/server/reds.h
+++ b/server/reds.h
@@ -101,6 +101,11 @@ SpiceCoreInterfaceInternal* 
reds_get_core_interface(RedsState *reds);
 void reds_update_client_mouse_allowed(RedsState *reds);
 MainDispatcher* reds_get_main_dispatcher(RedsState *reds);
 
+/* Get the recording object stored in RedsState.
+ * You should free with red_record_unref.
+ */
+struct RedRecord *reds_get_record(RedsState *reds);
+
 /* fd watches/timers */
 SpiceWatch *reds_core_watch_add(RedsState *reds,
 int fd, int event_mask,
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v4 3/3] red-channel: Use RedChannelCapabilities directly to pass capabilities

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 10:15:15AM -0500, Frediano Ziglio wrote:
> > Not really a big fan of having this kind of functions because we use
> > stack-allocated struct rather than just allocating a new struct. This
> > function should only be used on non-initialized RedChannelCapabilities
> > (this will leak otherwise), but it's non-obvious from the function name.
> > 
> 
> Maybe red_channel_capabilities_init_from_link_message ?

Better I guess,

Christophe

> 
> > 
> > Acked-by: Christophe Fergeau 
> > 
> > Christophe
> > 
> 
> Frediano


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v4 2/3] red-channel: Separate RedChannelCapabilities

[Jonathon Jongsma]

On Thu, 2017-03-02 at 16:04 +0100, Christophe Fergeau wrote:
> On Thu, Mar 02, 2017 at 09:55:46AM -0500, Frediano Ziglio wrote:
> > > > +/* GObject type that can be used to box RedChannelCapabilities
> > > > */
> > > > +extern GType red_channel_capabilities_type;
> > > > +#define TYPE_RED_CHANNEL_CAPABILITIES
> > > > red_channel_capabilities_type
> > > 
> > > RED_TYPE_CHANNEL_CAPABILITIES, similarly to RED_TYPE_CHANNEL,
> > > RED_TYPE_CHANNEL_CLIENT, ...
> > > 
> > 
> > If you do some grep the TYPE_xxx win (not much).
> 
> But there are 0 TYPE_RED_xxx.
> The scheme really is
> $NAMESPACE_TYPE_$TYPENAME, if NAMESPACE is empty, then TYPE_$TYPENAME
> We don't use TYPE_$NAMESPACE_$TYPENAME
> 

I agree with Christophe. It should be RED_TYPE_FOO for all types in the
Red namespace.

Jonathon
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v4 3/3] red-channel: Use RedChannelCapabilities directly to pass capabilities

[Frediano Ziglio]

> 
> On Thu, Mar 02, 2017 at 12:30:26PM +, Frediano Ziglio wrote:
> > diff --git a/server/red-worker.c b/server/red-worker.c
> > index 8735cd1..fbb7070 100644
> > --- a/server/red-worker.c
> > +++ b/server/red-worker.c
> > @@ -736,7 +736,7 @@ static void handle_dev_display_connect(void *opaque,
> > void *payload)
> >  spice_return_if_fail(display);
> >  
> >  dcc = dcc_new(display, msg->client, msg->stream, msg->migration,
> > -  msg->common_caps, msg->num_common_caps, msg->caps,
> > msg->num_caps,
> > +  &msg->caps,
> 
> I'd put this one on the same line as msg->migration.
> 
> >worker->image_compression, worker->jpeg_state,
> >worker->zlib_glz_state);
> >  if (!dcc) {
> >  return;
> > @@ -745,8 +745,7 @@ static void handle_dev_display_connect(void *opaque,
> > void *payload)
> >  guest_set_client_capabilities(worker);
> >  dcc_start(dcc);
> >  
> > -free(msg->caps);
> > -free(msg->common_caps);
> > +red_channel_capabilities_reset(&msg->caps);
> >  }
> >  
> >  static void handle_dev_display_disconnect(void *opaque, void *payload)
> > @@ -832,10 +831,8 @@ static void handle_dev_cursor_connect(void *opaque,
> > void *payload)
> >  spice_debug("cursor connect");
> >  cursor_channel_connect(worker->cursor_channel,
> > msg->client, msg->stream, msg->migration,
> > -   msg->common_caps, msg->num_common_caps,
> > -   msg->caps, msg->num_caps);
> > -free(msg->caps);
> > -free(msg->common_caps);
> > +   &msg->caps);
> > +red_channel_capabilities_reset(&msg->caps);
> >  }
> >  
> >  static void handle_dev_cursor_disconnect(void *opaque, void *payload)
> > diff --git a/server/reds.c b/server/reds.c
> > index f99dfda..6b8d1ef 100644
> > --- a/server/reds.c
> > +++ b/server/reds.c
> > @@ -1675,6 +1675,26 @@ static RedClient *reds_get_client(RedsState *reds)
> >  return reds->clients->data;
> >  }
> >  
> > +static void
> > +red_channel_capabilities_from_link_message(RedChannelCapabilities *caps,
> > +   const SpiceLinkMess *link_mess)
> > +{
> > +const uint32_t *raw_caps = (uint32_t *)((uint8_t *)link_mess +
> > link_mess->caps_offset);
> > +
> > +caps->num_common_caps = link_mess->num_common_caps;
> > +caps->common_caps = NULL;
> > +if (caps->num_common_caps) {
> > +caps->common_caps = spice_memdup(raw_caps,
> > + link_mess->num_common_caps *
> > sizeof(uint32_t));
> > +}
> > +caps->num_caps = link_mess->num_channel_caps;
> > +caps->caps = NULL;
> > +if (link_mess->num_channel_caps) {
> > +caps->caps = spice_memdup(raw_caps + link_mess->num_common_caps,
> > +  link_mess->num_channel_caps *
> > sizeof(uint32_t));
> > +}
> > +}
> 
> Not really a big fan of having this kind of functions because we use
> stack-allocated struct rather than just allocating a new struct. This
> function should only be used on non-initialized RedChannelCapabilities
> (this will leak otherwise), but it's non-obvious from the function name.
> 

Maybe red_channel_capabilities_init_from_link_message ?

> 
> Acked-by: Christophe Fergeau 
> 
> Christophe
> 

Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server 3/3] record: Allocate recording file globally from reds.c

[Jonathon Jongsma]

On Thu, 2017-03-02 at 10:38 +, Frediano Ziglio wrote:
> Allows to use recording function for multiple purposes.
> This will allow to register multiple screen VM or recording
> additional stuff like sound.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/red-worker.c   |  6 +-
>  server/reds-private.h |  2 ++
>  server/reds.c | 17 +
>  server/reds.h |  5 +
>  4 files changed, 25 insertions(+), 5 deletions(-)
> 
> diff --git a/server/red-worker.c b/server/red-worker.c
> index 93cb615..326e775 100644
> --- a/server/red-worker.c
> +++ b/server/red-worker.c
> @@ -1312,7 +1312,6 @@ RedWorker* red_worker_new(QXLInstance *qxl,
>  QXLDevInitInfo init_info;
>  RedWorker *worker;
>  Dispatcher *dispatcher;
> -const char *record_filename;
>  RedsState *reds = red_qxl_get_server(qxl->st);
>  RedChannel *channel;
>  
> @@ -1322,10 +1321,7 @@ RedWorker* red_worker_new(QXLInstance *qxl,
>  worker->core = event_loop_core;
>  worker->core.main_context = g_main_context_new();
>  
> -record_filename = getenv("SPICE_WORKER_RECORD_FILENAME");
> -if (record_filename) {
> -worker->record = red_record_new(record_filename);
> -}
> +worker->record = reds_get_record(reds);
>  dispatcher = red_qxl_get_dispatcher(qxl);
>  dispatcher_set_opaque(dispatcher, worker);
>  
> diff --git a/server/reds-private.h b/server/reds-private.h
> index e7e9ad7..07b7b38 100644
> --- a/server/reds-private.h
> +++ b/server/reds-private.h
> @@ -25,6 +25,7 @@
>  #include "main-channel.h"
>  #include "inputs-channel.h"
>  #include "stat-file.h"
> +#include "red-record-qxl.h"
>  
>  #define MIGRATE_TIMEOUT (MSEC_PER_SEC * 10)
>  #define MM_TIME_DELTA 400 /*ms*/
> @@ -135,6 +136,7 @@ struct RedsState {
>  SpiceCoreInterfaceInternal core;
>  GList *qxl_instances;
>  MainDispatcher *main_dispatcher;
> +RedRecord *record;
>  };
>  
>  #define FOREACH_QXL_INSTANCE(_reds, _iter, _qxl) \
> diff --git a/server/reds.c b/server/reds.c
> index f99dfda..9453a53 100644
> --- a/server/reds.c
> +++ b/server/reds.c
> @@ -3452,7 +3452,9 @@ static const char default_video_codecs[] =
> "spice:mjpeg;" GSTREAMER_CODECS;
>  /* new interface */
>  SPICE_GNUC_VISIBLE SpiceServer *spice_server_new(void)
>  {
> +const char *record_filename;
>  RedsState *reds = spice_new0(RedsState, 1);
> +
>  reds->config = spice_new0(RedServerConfig, 1);
>  reds->config->default_channel_security =
>  SPICE_CHANNEL_SECURITY_NONE | SPICE_CHANNEL_SECURITY_SSL;
> @@ -3484,6 +3486,12 @@ SPICE_GNUC_VISIBLE SpiceServer
> *spice_server_new(void)
>  reds->listen_socket = -1;
>  reds->secure_listen_socket = -1;
>  
> +/* This environment was in red-worker tso the "WORKER" in it.

typo: tso -> so

> + * For compatibility reason we maintain the old name */
> +record_filename = getenv("SPICE_WORKER_RECORD_FILENAME");
> +if (record_filename) {
> +reds->record = red_record_new(record_filename);
> +}
>  return reds;
>  }
>  
> @@ -4519,3 +4527,12 @@ static RedCharDeviceVDIPort
> *red_char_device_vdi_port_new(RedsState *reds)
>  "self-tokens",
> (guint64)REDS_NUM_INTERNAL_AGENT_MESSAGES,
>  NULL);
>  }
> +
> +RedRecord *reds_get_record(RedsState *reds)
> +{
> +if (reds->record) {
> +return red_record_ref(reds->record);
> +}
> +
> +return NULL;
> +}

I don't see reds->record unreffed anywhere. 

Jonathon

> diff --git a/server/reds.h b/server/reds.h
> index 28e3444..2748102 100644
> --- a/server/reds.h
> +++ b/server/reds.h
> @@ -101,6 +101,11 @@ SpiceCoreInterfaceInternal*
> reds_get_core_interface(RedsState *reds);
>  void reds_update_client_mouse_allowed(RedsState *reds);
>  MainDispatcher* reds_get_main_dispatcher(RedsState *reds);
>  
> +/* Get the recording object stored in RedsState.
> + * You should free with red_record_unref.
> + */
> +struct RedRecord *reds_get_record(RedsState *reds);
> +
>  /* fd watches/timers */
>  SpiceWatch *reds_core_watch_add(RedsState *reds,
>  int fd, int event_mask,
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] How to send a custom resolution message to windows/linux guest vdagent

[Jonathon Jongsma]

On Thu, 2017-03-02 at 03:58 -0300, Thiago Nascimento Araujo wrote:
> Hello,
> 
> Is there a way to send a spice message, connect to pipe, or any other
> method to contact vdservice/vdagent to create/simulate a resize to an
> arbitrary resolution or full screen effect caused by remote-viewer?
> 
> Any other ways I can connect to the named pipes (windows guests or
> linux guests) and watch/debug/learn. I cant find or connect to the
> windows guest named pipe and I got connection refused trying to socat
> to a port in linux guest.
> 
> I really need some guidance to fully understand how arbitrary
> resolutions are created using win/lnx/spice api.
> 
> Thanks in advance.
> 
> Or a way to 
> ___

Hi Thiago,

Seems your message got cut off or something.

My main question is: what is your end goal exactly? You say you're
trying to simulate a resize and therefore you want to connect to a
named pipe to do that. But there are probably better ways to do that,
depending on your final goal. Also note that in recent linux guests,
the vdagent executable is not really involved in the resolution
changing process at all. Once we know what you're actually trying to do
it will probably be easier to help you.

Cheers,
Jonathon
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server 2/3] record: Use reference counting for recording

[Jonathon Jongsma]

Acked-by: Jonathon Jongsma 


On Thu, 2017-03-02 at 10:38 +, Frediano Ziglio wrote:
> Allows to share the recording object.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/red-record-qxl.c | 19 ++-
>  server/red-record-qxl.h |  3 ++-
>  server/red-worker.c |  2 +-
>  3 files changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/server/red-record-qxl.c b/server/red-record-qxl.c
> index be6ac5a..e687c68 100644
> --- a/server/red-record-qxl.c
> +++ b/server/red-record-qxl.c
> @@ -32,6 +32,7 @@ struct RedRecord {
>  FILE *fd;
>  pthread_mutex_t lock;
>  unsigned int counter;
> +gint refs;
>  };
>  
>  #if 0
> @@ -910,17 +911,25 @@ RedRecord *red_record_new(const char *filename)
>  }
>  
>  record = g_new(RedRecord, 1);
> +record->refs = 1;
>  record->fd = f;
>  record->counter = 0;
>  pthread_mutex_init(&record->lock, NULL);
>  return record;
>  }
>  
> -void red_record_free(RedRecord *record)
> +RedRecord *red_record_ref(RedRecord *record)
>  {
> -if (record) {
> -fclose(record->fd);
> -pthread_mutex_destroy(&record->lock);
> -g_free(record);
> +g_atomic_int_inc(&record->refs);
> +return record;
> +}
> +
> +void red_record_unref(RedRecord *record)
> +{
> +if (!record || !g_atomic_int_dec_and_test(&record->refs)) {
> +return;
>  }
> +fclose(record->fd);
> +pthread_mutex_destroy(&record->lock);
> +g_free(record);
>  }
> diff --git a/server/red-record-qxl.h b/server/red-record-qxl.h
> index 0685393..293e24a 100644
> --- a/server/red-record-qxl.h
> +++ b/server/red-record-qxl.h
> @@ -33,7 +33,8 @@ typedef struct RedRecord RedRecord;
>   */
>  RedRecord* red_record_new(const char *filename);
>  
> -void red_record_free(RedRecord *record);
> +RedRecord *red_record_ref(RedRecord *record);
> +void red_record_unref(RedRecord *record);
>  
>  void red_record_primary_surface_create(RedRecord *record,
> QXLDevSurfaceCreate *surface,
> diff --git a/server/red-worker.c b/server/red-worker.c
> index 8735cd1..93cb615 100644
> --- a/server/red-worker.c
> +++ b/server/red-worker.c
> @@ -1461,7 +1461,7 @@ void red_worker_free(RedWorker *worker)
>  g_main_context_unref(worker->core.main_context);
>  
>  if (worker->record) {
> -red_record_free(worker->record);
> +red_record_unref(worker->record);
>  }
>  memslot_info_destroy(&worker->mem_slots);
>  free(worker);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server 1/3] record: Synchronize write to record file

[Jonathon Jongsma]

Acked-by: Jonathon Jongsma 


On Thu, 2017-03-02 at 10:38 +, Frediano Ziglio wrote:
> The synchronization code is required to avoid mixing writing
> from multiple threads.
> Following patches will add this feature.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/red-record-qxl.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/server/red-record-qxl.c b/server/red-record-qxl.c
> index ee22236..be6ac5a 100644
> --- a/server/red-record-qxl.c
> +++ b/server/red-record-qxl.c
> @@ -30,6 +30,7 @@
>  
>  struct RedRecord {
>  FILE *fd;
> +pthread_mutex_t lock;
>  unsigned int counter;
>  };
>  
> @@ -794,15 +795,17 @@ void
> red_record_primary_surface_create(RedRecord *record,
>  {
>  FILE *fd = record->fd;
>  
> +pthread_mutex_lock(&record->lock);
>  fprintf(fd, "%d %d %d %d\n", surface->width, surface->height,
>  surface->stride, surface->format);
>  fprintf(fd, "%d %d %d %d\n", surface->position, surface-
> >mouse_mode,
>  surface->flags, surface->type);
>  write_binary(fd, "data", line_0 ? abs(surface->stride)*surface-
> >height : 0,
>  line_0);
> +pthread_mutex_unlock(&record->lock);
>  }
>  
> -void red_record_event(RedRecord *record, int what, uint32_t type)
> +static void red_record_event_unlocked(RedRecord *record, int what,
> uint32_t type)
>  {
>  red_time_t ts = spice_get_monotonic_time_ns();
>  // TODO: record the size of the packet in the header. This would
> make
> @@ -813,12 +816,20 @@ void red_record_event(RedRecord *record, int
> what, uint32_t type)
>  fprintf(record->fd, "event %u %d %u %"PRIu64"\n", record-
> >counter++, what, type, ts);
>  }
>  
> +void red_record_event(RedRecord *record, int what, uint32_t type)
> +{
> +pthread_mutex_lock(&record->lock);
> +red_record_event_unlocked(record, what, type);
> +pthread_mutex_unlock(&record->lock);
> +}
> +
>  void red_record_qxl_command(RedRecord *record, RedMemSlotInfo
> *slots,
>  QXLCommandExt ext_cmd)
>  {
>  FILE *fd = record->fd;
>  
> -red_record_event(record, 0, ext_cmd.cmd.type);
> +pthread_mutex_lock(&record->lock);
> +red_record_event_unlocked(record, 0, ext_cmd.cmd.type);
>  
>  switch (ext_cmd.cmd.type) {
>  case QXL_CMD_DRAW:
> @@ -837,6 +848,7 @@ void red_record_qxl_command(RedRecord *record,
> RedMemSlotInfo *slots,
>  red_record_cursor_cmd(fd, slots, ext_cmd.group_id,
> ext_cmd.cmd.data);
>  break;
>  }
> +pthread_mutex_unlock(&record->lock);
>  }
>  
>  /**
> @@ -900,6 +912,7 @@ RedRecord *red_record_new(const char *filename)
>  record = g_new(RedRecord, 1);
>  record->fd = f;
>  record->counter = 0;
> +pthread_mutex_init(&record->lock, NULL);
>  return record;
>  }
>  
> @@ -907,6 +920,7 @@ void red_record_free(RedRecord *record)
>  {
>  if (record) {
>  fclose(record->fd);
> +pthread_mutex_destroy(&record->lock);
>  g_free(record);
>  }
>  }
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v4 3/3] red-channel: Use RedChannelCapabilities directly to pass capabilities

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 12:30:26PM +, Frediano Ziglio wrote:
> diff --git a/server/red-worker.c b/server/red-worker.c
> index 8735cd1..fbb7070 100644
> --- a/server/red-worker.c
> +++ b/server/red-worker.c
> @@ -736,7 +736,7 @@ static void handle_dev_display_connect(void *opaque, void 
> *payload)
>  spice_return_if_fail(display);
>  
>  dcc = dcc_new(display, msg->client, msg->stream, msg->migration,
> -  msg->common_caps, msg->num_common_caps, msg->caps, 
> msg->num_caps,
> +  &msg->caps,

I'd put this one on the same line as msg->migration.

>worker->image_compression, worker->jpeg_state, 
> worker->zlib_glz_state);
>  if (!dcc) {
>  return;
> @@ -745,8 +745,7 @@ static void handle_dev_display_connect(void *opaque, void 
> *payload)
>  guest_set_client_capabilities(worker);
>  dcc_start(dcc);
>  
> -free(msg->caps);
> -free(msg->common_caps);
> +red_channel_capabilities_reset(&msg->caps);
>  }
>  
>  static void handle_dev_display_disconnect(void *opaque, void *payload)
> @@ -832,10 +831,8 @@ static void handle_dev_cursor_connect(void *opaque, void 
> *payload)
>  spice_debug("cursor connect");
>  cursor_channel_connect(worker->cursor_channel,
> msg->client, msg->stream, msg->migration,
> -   msg->common_caps, msg->num_common_caps,
> -   msg->caps, msg->num_caps);
> -free(msg->caps);
> -free(msg->common_caps);
> +   &msg->caps);
> +red_channel_capabilities_reset(&msg->caps);
>  }
>  
>  static void handle_dev_cursor_disconnect(void *opaque, void *payload)
> diff --git a/server/reds.c b/server/reds.c
> index f99dfda..6b8d1ef 100644
> --- a/server/reds.c
> +++ b/server/reds.c
> @@ -1675,6 +1675,26 @@ static RedClient *reds_get_client(RedsState *reds)
>  return reds->clients->data;
>  }
>  
> +static void
> +red_channel_capabilities_from_link_message(RedChannelCapabilities *caps,
> +   const SpiceLinkMess *link_mess)
> +{
> +const uint32_t *raw_caps = (uint32_t *)((uint8_t *)link_mess + 
> link_mess->caps_offset);
> +
> +caps->num_common_caps = link_mess->num_common_caps;
> +caps->common_caps = NULL;
> +if (caps->num_common_caps) {
> +caps->common_caps = spice_memdup(raw_caps,
> + link_mess->num_common_caps * 
> sizeof(uint32_t));
> +}
> +caps->num_caps = link_mess->num_channel_caps;
> +caps->caps = NULL;
> +if (link_mess->num_channel_caps) {
> +caps->caps = spice_memdup(raw_caps + link_mess->num_common_caps,
> +  link_mess->num_channel_caps * 
> sizeof(uint32_t));
> +}
> +}

Not really a big fan of having this kind of functions because we use
stack-allocated struct rather than just allocating a new struct. This
function should only be used on non-initialized RedChannelCapabilities
(this will leak otherwise), but it's non-obvious from the function name.


Acked-by: Christophe Fergeau 

Christophe


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v4 2/3] red-channel: Separate RedChannelCapabilities

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 09:55:46AM -0500, Frediano Ziglio wrote:
> > > +/* GObject type that can be used to box RedChannelCapabilities */
> > > +extern GType red_channel_capabilities_type;
> > > +#define TYPE_RED_CHANNEL_CAPABILITIES red_channel_capabilities_type
> > 
> > RED_TYPE_CHANNEL_CAPABILITIES, similarly to RED_TYPE_CHANNEL,
> > RED_TYPE_CHANNEL_CLIENT, ...
> > 
> 
> If you do some grep the TYPE_xxx win (not much).

But there are 0 TYPE_RED_xxx.
The scheme really is
$NAMESPACE_TYPE_$TYPENAME, if NAMESPACE is empty, then TYPE_$TYPENAME
We don't use TYPE_$NAMESPACE_$TYPENAME

Christophe


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice v11] dcc: handle preferred video codec message

[Frediano Ziglio]

> 
> From: Victor Toso 
> 
> [0] SPICE_MSGC_DISPLAY_PREFERRED_VIDEO_CODEC_TYPE
> 
> This message provides a list of video codecs based on client's order
> of preference.
> 
> We duplicate the video codecs array from reds.c and sort it using the
> order of codecs as reference.
> 
> This message will not change an ongoing streaming but it could change
> newly created streams depending the rank value of each video codec
> that can be set by spice_server_set_video_codecs()
> 
> Signed-off-by: Victor Toso 

Good for me.

Did some last testing on the patch. Was actually not easy to write
a test.

Only one change. You should include glib-compat.h in dcc.c to
make it compile in RHEL6.

Beside that,

Acked-by: Frediano Ziglio 

Frediano

> ---
>  server/dcc-private.h |   6 +++
>  server/dcc.c | 125
>  +++
>  server/dcc.h |   1 +
>  server/display-channel.c |   2 +
>  server/stream.c  |   3 +-
>  5 files changed, 135 insertions(+), 2 deletions(-)
> 
> diff --git a/server/dcc-private.h b/server/dcc-private.h
> index 64b32a7..242af10 100644
> --- a/server/dcc-private.h
> +++ b/server/dcc-private.h
> @@ -51,6 +51,12 @@ struct DisplayChannelClientPrivate
>  int num_pixmap_cache_items;
>  } send_data;
>  
> +/* Host preferred video-codec order sorted with client preferred */
> +GArray *preferred_video_codecs;
> +/* Array with SPICE_VIDEO_CODEC_TYPE_ENUM_END elements, with the client
> + * preference order (index) as value */
> +GArray *client_preferred_video_codecs;
> +
>  uint8_t surface_client_created[NUM_SURFACES];
>  QRegion surface_client_lossy_region[NUM_SURFACES];
>  
> diff --git a/server/dcc.c b/server/dcc.c
> index 373dad9..6c49ed5 100644
> --- a/server/dcc.c
> +++ b/server/dcc.c
> @@ -39,6 +39,8 @@ enum
>  PROP_ZLIB_GLZ_STATE
>  };
>  
> +static void on_display_video_codecs_update(GObject *gobject, GParamSpec
> *pspec, gpointer user_data);
> +
>  static void
>  display_channel_client_get_property(GObject *object,
>  guint property_id,
> @@ -99,12 +101,19 @@ display_channel_client_constructed(GObject *object)
>  dcc_init_stream_agents(self);
>  
>  image_encoders_init(&self->priv->encoders,
>  &DCC_TO_DC(self)->priv->encoder_shared_data);
> +
> +g_signal_connect(DCC_TO_DC(self), "notify::video-codecs",
> + G_CALLBACK(on_display_video_codecs_update), self);
>  }
>  
>  static void
>  display_channel_client_finalize(GObject *object)
>  {
>  DisplayChannelClient *self = DISPLAY_CHANNEL_CLIENT(object);
> +
> +g_signal_handlers_disconnect_by_func(DCC_TO_DC(self),
> on_display_video_codecs_update, self);
> +g_clear_pointer(&self->priv->preferred_video_codecs, g_array_unref);
> +g_clear_pointer(&self->priv->client_preferred_video_codecs,
> g_array_unref);
>  g_free(self->priv);
>  
>  G_OBJECT_CLASS(display_channel_client_parent_class)->finalize(object);
> @@ -1105,6 +1114,119 @@ static int
> dcc_handle_preferred_compression(DisplayChannelClient *dcc,
>  return TRUE;
>  }
>  
> +
> +/* TODO: Client preference should only be considered when host has
> video-codecs
> + * with the same priority value. At the moment, the video-codec GArray will
> be
> + * sorted following only the client's preference (@user_data)
> + *
> + * example:
> + * host encoding preference: gstreamer:mjpeg;gstreamer:vp8;gstreamer:h264
> + * client decoding preference: h264, vp9, mjpeg
> + * result: gstreamer:h264;gstreamer:mjpeg;gstreamer:vp8
> + */
> +static gint sort_video_codecs_by_client_preference(gconstpointer a_pointer,
> +   gconstpointer b_pointer,
> +   gpointer user_data)
> +{
> +const RedVideoCodec *a = a_pointer;
> +const RedVideoCodec *b = b_pointer;
> +GArray *client_pref = user_data;
> +
> +return (g_array_index(client_pref, gint, a->type) -
> +g_array_index(client_pref, gint, b->type));
> +}
> +
> +static void dcc_update_preferred_video_codecs(DisplayChannelClient *dcc)
> +{
> +guint i;
> +GArray *video_codecs, *server_codecs;
> +GString *msg;
> +
> +server_codecs = display_channel_get_video_codecs(DCC_TO_DC(dcc));
> +spice_return_if_fail(server_codecs != NULL);
> +
> +/* Copy current host preference */
> +video_codecs = g_array_sized_new(FALSE, FALSE, sizeof(RedVideoCodec),
> server_codecs->len);
> +g_array_append_vals(video_codecs, server_codecs->data,
> server_codecs->len);
> +
> +/* Sort the copy of current host preference based on client's preference
> */
> +g_array_sort_with_data(video_codecs,
> sort_video_codecs_by_client_preference,
> +   dcc->priv->client_preferred_video_codecs);
> +g_clear_pointer(&dcc->priv->preferred_video_codecs, g_array_unref);
> +dcc->priv->preferred_video_codecs = video_codecs;
> +
> + 

Re: [Spice-devel] [PATCH spice-server v4 2/3] red-channel: Separate RedChannelCapabilities

[Frediano Ziglio]

> 
> On Thu, Mar 02, 2017 at 12:30:25PM +, Frediano Ziglio wrote:
> > Add function to initialize and destroy this type.
> > Add GType type for boxing it.
> > These changes a in preparation for next patch.
> > 
> > Signed-off-by: Frediano Ziglio 
> > ---
> >  server/Makefile.am|  2 ++
> >  server/red-channel-capabilities.c | 68
> >  +++
> >  server/red-channel-capabilities.h | 51 +
> >  server/red-channel.h  |  8 +
> >  4 files changed, 122 insertions(+), 7 deletions(-)
> >  create mode 100644 server/red-channel-capabilities.c
> >  create mode 100644 server/red-channel-capabilities.h
> > 
> > diff --git a/server/Makefile.am b/server/Makefile.am
> > index a043660..49c0822 100644
> > --- a/server/Makefile.am
> > +++ b/server/Makefile.am
> > @@ -101,6 +101,8 @@ libserver_la_SOURCES =  \
> > red-channel.h   \
> > red-channel-client.c\
> > red-channel-client.h\
> > +   red-channel-capabilities.c  \
> > +   red-channel-capabilities.h  \
> > red-client.c\
> > red-client.h\
> > red-common.h\
> > diff --git a/server/red-channel-capabilities.c
> > b/server/red-channel-capabilities.c
> > new file mode 100644
> > index 000..eacb338
> > --- /dev/null
> > +++ b/server/red-channel-capabilities.c
> > @@ -0,0 +1,68 @@
> > +/*
> > +   Copyright (C) 2017 Red Hat, Inc.
> > +
> > +   This library is free software; you can redistribute it and/or
> > +   modify it under the terms of the GNU Lesser General Public
> > +   License as published by the Free Software Foundation; either
> > +   version 2.1 of the License, or (at your option) any later version.
> > +
> > +   This library is distributed in the hope that it will be useful,
> > +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > +   Lesser General Public License for more details.
> > +
> > +   You should have received a copy of the GNU Lesser General Public
> > +   License along with this library; if not, see
> > .
> > +*/
> > +#ifdef HAVE_CONFIG_H
> > +#include 
> > +#endif
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "red-channel-capabilities.h"
> > +
> > +GType red_channel_capabilities_type;
> > +
> > +void red_channel_capabilities_init(RedChannelCapabilities *dest,
> > +   const RedChannelCapabilities *caps)
> > +{
> > +*dest = *caps;
> > +if (caps->common_caps) {
> > +dest->common_caps = spice_memdup(caps->common_caps,
> > + caps->num_common_caps *
> > sizeof(uint32_t));
> > +}
> > +if (caps->num_caps) {
> > +dest->caps = spice_memdup(caps->caps, caps->num_caps *
> > sizeof(uint32_t));
> > +}
> > +}
> > +
> > +void red_channel_capabilities_reset(RedChannelCapabilities *caps)
> > +{
> > +free(caps->common_caps);
> > +free(caps->caps);
> > +memset(caps, 0, sizeof(*caps));
> > +}
> > +
> > +static RedChannelCapabilities *red_channel_capabilities_dup(const
> > RedChannelCapabilities *caps)
> > +{
> > +RedChannelCapabilities *res = spice_new(RedChannelCapabilities, 1);
> > +red_channel_capabilities_init(res, caps);
> > +return res;
> > +}
> > +
> > +static void red_channel_capabilities_free(RedChannelCapabilities *caps)
> > +{
> > +red_channel_capabilities_reset(caps);
> > +free(caps);
> > +}
> > +
> > +SPICE_CONSTRUCTOR_FUNC(red_channel_capabilities_construct)
> > +{
> > +red_channel_capabilities_type =
> > +g_boxed_type_register_static("red_channel_capabilities_type",
> 
> Nit as well, but "RedChannelCapabilities"? Or you prefer to keep the
> same name as the GType variable that you use?
> 

Honestly I was going to use a GUID like Windows !
No preference, as long as it's unique, "RedChannelCapabilities" is fine.

> > + (GBoxedCopyFunc)
> > red_channel_capabilities_dup,
> > + (GBoxedFreeFunc)
> > red_channel_capabilities_free);
> > +}
> > diff --git a/server/red-channel-capabilities.h
> > b/server/red-channel-capabilities.h
> > new file mode 100644
> > index 000..299409d
> > --- /dev/null
> > +++ b/server/red-channel-capabilities.h
> > @@ -0,0 +1,51 @@
> > +/* -*- Mode: C; c-basic-offset: 4; indent-tabs-mode: nil -*- */
> > +/*
> > +   Copyright (C) 2009-2017 Red Hat, Inc.
> > +
> > +   This library is free software; you can redistribute it and/or
> > +   modify it under the terms of the GNU Lesser General Public
> > +   License as published by the Free Software Foundation; either
> > +   version 2.1 of the License, or (at your option) any later version.
> > +
> > +   This library is d

Re: [Spice-devel] [PATCH spice-server v4 2/3] red-channel: Separate RedChannelCapabilities

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 12:30:25PM +, Frediano Ziglio wrote:
> Add function to initialize and destroy this type.
> Add GType type for boxing it.
> These changes a in preparation for next patch.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/Makefile.am|  2 ++
>  server/red-channel-capabilities.c | 68 
> +++
>  server/red-channel-capabilities.h | 51 +
>  server/red-channel.h  |  8 +
>  4 files changed, 122 insertions(+), 7 deletions(-)
>  create mode 100644 server/red-channel-capabilities.c
>  create mode 100644 server/red-channel-capabilities.h
> 
> diff --git a/server/Makefile.am b/server/Makefile.am
> index a043660..49c0822 100644
> --- a/server/Makefile.am
> +++ b/server/Makefile.am
> @@ -101,6 +101,8 @@ libserver_la_SOURCES =\
>   red-channel.h   \
>   red-channel-client.c\
>   red-channel-client.h\
> + red-channel-capabilities.c  \
> + red-channel-capabilities.h  \
>   red-client.c\
>   red-client.h\
>   red-common.h\
> diff --git a/server/red-channel-capabilities.c 
> b/server/red-channel-capabilities.c
> new file mode 100644
> index 000..eacb338
> --- /dev/null
> +++ b/server/red-channel-capabilities.c
> @@ -0,0 +1,68 @@
> +/*
> +   Copyright (C) 2017 Red Hat, Inc.
> +
> +   This library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   This library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with this library; if not, see 
> .
> +*/
> +#ifdef HAVE_CONFIG_H
> +#include 
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "red-channel-capabilities.h"
> +
> +GType red_channel_capabilities_type;
> +
> +void red_channel_capabilities_init(RedChannelCapabilities *dest,
> +   const RedChannelCapabilities *caps)
> +{
> +*dest = *caps;
> +if (caps->common_caps) {
> +dest->common_caps = spice_memdup(caps->common_caps,
> + caps->num_common_caps * 
> sizeof(uint32_t));
> +}
> +if (caps->num_caps) {
> +dest->caps = spice_memdup(caps->caps, caps->num_caps * 
> sizeof(uint32_t));
> +}
> +}
> +
> +void red_channel_capabilities_reset(RedChannelCapabilities *caps)
> +{
> +free(caps->common_caps);
> +free(caps->caps);
> +memset(caps, 0, sizeof(*caps));
> +}
> +
> +static RedChannelCapabilities *red_channel_capabilities_dup(const 
> RedChannelCapabilities *caps)
> +{
> +RedChannelCapabilities *res = spice_new(RedChannelCapabilities, 1);
> +red_channel_capabilities_init(res, caps);
> +return res;
> +}
> +
> +static void red_channel_capabilities_free(RedChannelCapabilities *caps)
> +{
> +red_channel_capabilities_reset(caps);
> +free(caps);
> +}
> +
> +SPICE_CONSTRUCTOR_FUNC(red_channel_capabilities_construct)
> +{
> +red_channel_capabilities_type =
> +g_boxed_type_register_static("red_channel_capabilities_type",

Nit as well, but "RedChannelCapabilities"? Or you prefer to keep the
same name as the GType variable that you use?

> + (GBoxedCopyFunc) 
> red_channel_capabilities_dup,
> + (GBoxedFreeFunc) 
> red_channel_capabilities_free);
> +}
> diff --git a/server/red-channel-capabilities.h 
> b/server/red-channel-capabilities.h
> new file mode 100644
> index 000..299409d
> --- /dev/null
> +++ b/server/red-channel-capabilities.h
> @@ -0,0 +1,51 @@
> +/* -*- Mode: C; c-basic-offset: 4; indent-tabs-mode: nil -*- */
> +/*
> +   Copyright (C) 2009-2017 Red Hat, Inc.
> +
> +   This library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   This library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with this library; if not, 

Re: [Spice-devel] [PATCH spice-server 3/3] tests: Reuse GLib compatibility code

[Frediano Ziglio]

> 
> On Thu, Mar 02, 2017 at 01:50:03PM +, Frediano Ziglio wrote:
> > Instead of disabling the code use the compatibility functions.
> > 
> > Signed-off-by: Frediano Ziglio 
> > ---
> >  server/tests/test-codecs-parsing.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/server/tests/test-codecs-parsing.c
> > b/server/tests/test-codecs-parsing.c
> > index 571d8ab..838a80c 100644
> > --- a/server/tests/test-codecs-parsing.c
> > +++ b/server/tests/test-codecs-parsing.c
> > @@ -46,8 +46,9 @@ static void codecs_good(void)
> >  }
> >  
> >  /* g_test_expect_message is available since Glib 2.34 */
> > -#if GLIB_CHECK_VERSION(2, 34, 0)
> > +#ifdef G_GNUC_BEGIN_IGNORE_DEPRECATIONS
> >  G_GNUC_BEGIN_IGNORE_DEPRECATIONS
> > +#endif
> 
> Not consistent with what was done for test-vdagent which uses
> -UGLIB_MAX_VERSION in Makefile.am.
> If this form is preferred over disabling the version checks, I'll send a
> patch for test-vdagent.
> 
> Christophe
> 

I'll copy vdagent way

Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server 3/3] tests: Reuse GLib compatibility code

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 01:50:03PM +, Frediano Ziglio wrote:
> Instead of disabling the code use the compatibility functions.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/tests/test-codecs-parsing.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/server/tests/test-codecs-parsing.c 
> b/server/tests/test-codecs-parsing.c
> index 571d8ab..838a80c 100644
> --- a/server/tests/test-codecs-parsing.c
> +++ b/server/tests/test-codecs-parsing.c
> @@ -46,8 +46,9 @@ static void codecs_good(void)
>  }
>  
>  /* g_test_expect_message is available since Glib 2.34 */
> -#if GLIB_CHECK_VERSION(2, 34, 0)
> +#ifdef G_GNUC_BEGIN_IGNORE_DEPRECATIONS
>  G_GNUC_BEGIN_IGNORE_DEPRECATIONS
> +#endif

Not consistent with what was done for test-vdagent which uses
-UGLIB_MAX_VERSION in Makefile.am.
If this form is preferred over disabling the version checks, I'll send a
patch for test-vdagent.

Christophe


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server 2/3] tests: Move some specific GLib compatibility to compatibility file

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 01:50:02PM +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio 
> ---
>  server/glib-compat.h   |  8 
>  server/tests/test-codecs-parsing.c |  6 +-
>  server/tests/test-leaks.c  |  7 +--
>  server/tests/test-options.c|  7 +--
>  server/tests/test-stat-file.c  | 10 +-
>  5 files changed, 12 insertions(+), 26 deletions(-)

I'd also move these to a tests/test-glib-compat.h  file

Acked-by: Christophe Fergeau 

> 
> diff --git a/server/glib-compat.h b/server/glib-compat.h
> index 9d75701..557e13e 100644
> --- a/server/glib-compat.h
> +++ b/server/glib-compat.h
> @@ -72,4 +72,12 @@ void g_test_expect_message(const gchar *log_domain, 
> GLogLevelFlags log_level,
> const gchar *pattern);
>  #endif
>  
> +/* GLIB_CHECK_VERSION(2, 40, 0) */
> +#ifndef g_assert_nonnull
> +#define g_assert_nonnull g_assert
> +#endif
> +#ifndef g_assert_null
> +#define g_assert_null(ptr) g_assert((ptr) == NULL)
> +#endif
> +
>  #endif /* GLIB_COMPAT_H_ */
> diff --git a/server/tests/test-codecs-parsing.c 
> b/server/tests/test-codecs-parsing.c
> index 5af2e5d..571d8ab 100644
> --- a/server/tests/test-codecs-parsing.c
> +++ b/server/tests/test-codecs-parsing.c
> @@ -16,13 +16,9 @@
> License along with this library; if not, see 
> .
>  */
>  #include 
> -#include 
>  #include 
>  
> -/* GLIB_CHECK_VERSION(2, 40, 0) */
> -#ifndef g_assert_nonnull
> -#define g_assert_nonnull g_assert
> -#endif
> +#include "glib-compat.h"
>  
>  static void codecs_good(void)
>  {
> diff --git a/server/tests/test-leaks.c b/server/tests/test-leaks.c
> index b8521f4..21ffd5c 100644
> --- a/server/tests/test-leaks.c
> +++ b/server/tests/test-leaks.c
> @@ -16,16 +16,11 @@
> License along with this library; if not, see 
> .
>  */
>  #include 
> -#include 
>  #include 
>  
> +#include "glib-compat.h"
>  #include "basic-event-loop.h"
>  
> -/* GLIB_CHECK_VERSION(2, 40, 0) */
> -#ifndef g_assert_nonnull
> -#define g_assert_nonnull g_assert
> -#endif
> -
>  static void leaks(void)
>  {
>  int result;
> diff --git a/server/tests/test-options.c b/server/tests/test-options.c
> index 0cfd4b3..2c612c3 100644
> --- a/server/tests/test-options.c
> +++ b/server/tests/test-options.c
> @@ -16,16 +16,11 @@
> License along with this library; if not, see 
> .
>  */
>  #include 
> -#include 
>  #include 
>  
> +#include "glib-compat.h"
>  #include "basic-event-loop.h"
>  
> -/* GLIB_CHECK_VERSION(2, 40, 0) */
> -#ifndef g_assert_nonnull
> -#define g_assert_nonnull g_assert
> -#endif
> -
>  static void agent_options(void)
>  {
>  SpiceCoreInterface *core ;
> diff --git a/server/tests/test-stat-file.c b/server/tests/test-stat-file.c
> index 40cf37d..502aadd 100644
> --- a/server/tests/test-stat-file.c
> +++ b/server/tests/test-stat-file.c
> @@ -19,19 +19,11 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
> +#include "glib-compat.h"
>  #include "stat-file.h"
>  
> -/* GLIB_CHECK_VERSION(2, 40, 0) */
> -#ifndef g_assert_nonnull
> -#define g_assert_nonnull g_assert
> -#endif
> -#ifndef g_assert_null
> -#define g_assert_null(ptr) g_assert((ptr) == NULL)
> -#endif
> -
>  static void stat_file(void)
>  {
>  RedStatFile *stat_file;
> -- 
> 2.9.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server 1/3] tests: Move some glib compatibility code to a separate file

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 01:50:01PM +, Frediano Ziglio wrote:
> Allow to reuse this code in other tests.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/glib-compat.h|   9 
>  server/tests/Makefile.am|   1 +
>  server/tests/test-glib-compat.c | 112 
> 
>  server/tests/test-vdagent.c |  92 +
>  4 files changed, 123 insertions(+), 91 deletions(-)
>  create mode 100644 server/tests/test-glib-compat.c
> 
> diff --git a/server/glib-compat.h b/server/glib-compat.h
> index 50a0783..9d75701 100644
> --- a/server/glib-compat.h
> +++ b/server/glib-compat.h
> @@ -63,4 +63,13 @@ g_queue_remove_boolean(GQueue *queue, gconstpointer data)
>  #define g_queue_remove g_queue_remove_boolean
>  #endif
>  
> +#if !GLIB_CHECK_VERSION(2, 34, 0)
> +void g_test_assert_expected_messages_internal(const char *domain,
> +  const char *file, int line, 
> const char *func);
> +#define g_test_assert_expected_messages() \
> +g_test_assert_expected_messages_internal (G_LOG_DOMAIN, __FILE__, 
> __LINE__, G_STRFUNC)
> +void g_test_expect_message(const gchar *log_domain, GLogLevelFlags log_level,
> +   const gchar *pattern);
> +#endif
> +

This belongs to a new tests/test-glib-compat.h (using these fallback
implementations is going to fail at link time if not built together with
test-glib-compat.c)


>  #endif /* GLIB_COMPAT_H_ */
> diff --git a/server/tests/Makefile.am b/server/tests/Makefile.am
> index dd04834..ca70e22 100644
> --- a/server/tests/Makefile.am
> +++ b/server/tests/Makefile.am
> @@ -25,6 +25,7 @@ libtest_a_SOURCES = \
>   basic-event-loop.h  \
>   test-display-base.c \
>   test-display-base.h \
> + test-glib-compat.c  \
>   $(NULL)
>  
>  LDADD =  \
> diff --git a/server/tests/test-glib-compat.c b/server/tests/test-glib-compat.c
> new file mode 100644
> index 000..9b47dc6
> --- /dev/null
> +++ b/server/tests/test-glib-compat.c
> @@ -0,0 +1,112 @@
> +/* -*- Mode: C; c-basic-offset: 4; indent-tabs-mode: nil -*- */
> +/*
> +   Copyright (C) 2017 Red Hat, Inc.
> +
> +   This library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   This library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with this library; if not, see 
> .
> +*/
> +
> +#include 
> +
> +#include "glib-compat.h"
> +
> +#if !GLIB_CHECK_VERSION(2, 34, 0)
> +
> +/* The code in this #ifdef block is taken from glib and is licensed under the
> + * GNU Lesser General Public License version 2 or later.
> + *
> + * Copyright (C) 1995-1997  Peter Mattis, Spencer Kimball and Josh MacDonald
> + * Modified by the GLib Team and others 1997-2000.  See GLib AUTHORS
> + * file for a list of people on the GLib Team.

Since it's in its own  file now, maybe move that to the copyright block?

Acked-by: Christophe Fergeau 

Christophe


> + */
> +
> +typedef struct {
> +gchar *log_domain;
> +GLogLevelFlags log_level;
> +gchar *pattern;
> +} GTestExpectedMessage;
> +
> +static GSList *expected_messages = NULL;
> +
> +static gboolean fatal_log_filter(const gchar *log_domain,
> + GLogLevelFlags log_level,
> + const gchar *msg,
> + gpointer user_data)
> +{
> +GTestExpectedMessage *expected = expected_messages->data;
> +
> +if ((g_strcmp0(expected->log_domain, log_domain) == 0)
> +&& ((log_level & expected->log_level) == expected->log_level)
> +&& (g_pattern_match_simple(expected->pattern, msg))) {
> +expected_messages = g_slist_delete_link(expected_messages,
> +expected_messages);
> +g_free (expected->log_domain);
> +g_free (expected->pattern);
> +g_free (expected);
> +
> +return FALSE;
> +}
> +return TRUE;
> +}
> +
> +void
> +g_test_assert_expected_messages_internal (const char *domain,
> +  const char *file,
> +  int line,
> +  const char *func)
> +{
> +  if (expected_messages)
> +{
> +  GTestExpectedMessage *expected

Re: [Spice-devel] [spice-gtk v3 4/6] spice_channel_read_wire: move variables to internal scope

[Christophe Fergeau]

Acked-by: Christophe Fergeau 

On Tue, Feb 28, 2017 at 12:21:49PM +0100, Victor Toso wrote:
> From: Victor Toso 
> 
> And avoid single line if plus comment
> 
> Signed-off-by: Victor Toso 
> ---
>  src/spice-channel.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/src/spice-channel.c b/src/spice-channel.c
> index f2d1b8a..c2e8a01 100644
> --- a/src/spice-channel.c
> +++ b/src/spice-channel.c
> @@ -1048,12 +1048,15 @@ static int 
> spice_channel_read_wire_nonblocking(SpiceChannel *channel,
>  static int spice_channel_read_wire(SpiceChannel *channel, void *data, size_t 
> len)
>  {
>  SpiceChannelPrivate *c = channel->priv;
> -GIOCondition cond;
> -gssize ret;
>  
>  while (TRUE) {
> +gssize ret;
> +GIOCondition cond;
>  
> -if (c->has_error) return 0; /* has_error is set by disconnect(), 
> return no error */
> +if (c->has_error) {
> +/* has_error is set by disconnect(), return no error */
> +return 0;
> +}
>  
>  ret = spice_channel_read_wire_nonblocking(channel, data, len, &cond);
>  
> -- 
> 2.9.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v4 3/6] spice_channel_read_wire: prefer while(TRUE) instead of goto

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 03:08:11PM +0100, Victor Toso wrote:
> From: Victor Toso 
> 
> Although this is likely to be a single loop iteration based on the
> implementation of g_coroutine_socket_wait(), using goto to reiterate
> in the code should be avoided based on spice style recommendation.
> 
> This also make it easier to add follow up changes that can increase
> the loop iterations.
> 
> This patch changes:
>  * The reread label with a while(TRUE);
>  * The goto keyword with continue;
> 
> All other changes are only related to new indentation.

In other words, git show -w is:

diff --git a/src/spice-channel.c b/src/spice-channel.c
index 999c615..f2d1b8a 100644
--- a/src/spice-channel.c
+++ b/src/spice-channel.c
@@ -1051,7 +1051,7 @@ static int spice_channel_read_wire(SpiceChannel *channel, 
void *data, size_t len
 GIOCondition cond;
 gssize ret;

-reread:
+while (TRUE) {

 if (c->has_error) return 0; /* has_error is set by disconnect(), 
return no error */

@@ -1061,7 +1061,7 @@ reread:
 if (cond != 0) {
 // TODO: should use 
g_pollable_input/output_stream_create_source() ?
 g_coroutine_socket_wait(&c->coroutine, c->sock, cond);
-goto reread;
+continue;
 } else {
 c->has_error = TRUE;
 return -errno;
@@ -1075,6 +1075,7 @@ reread:

 return ret;
 }
+}

Acked-by: Christophe Fergeau 


> 
> Signed-off-by: Victor Toso 
> ---
>  src/spice-channel.c | 35 ++-
>  1 file changed, 18 insertions(+), 17 deletions(-)
> 
> diff --git a/src/spice-channel.c b/src/spice-channel.c
> index 999c615..f2d1b8a 100644
> --- a/src/spice-channel.c
> +++ b/src/spice-channel.c
> @@ -1051,29 +1051,30 @@ static int spice_channel_read_wire(SpiceChannel 
> *channel, void *data, size_t len
>  GIOCondition cond;
>  gssize ret;
>  
> -reread:
> +while (TRUE) {
>  
> -if (c->has_error) return 0; /* has_error is set by disconnect(), return 
> no error */
> +if (c->has_error) return 0; /* has_error is set by disconnect(), 
> return no error */
>  
> -ret = spice_channel_read_wire_nonblocking(channel, data, len, &cond);
> +ret = spice_channel_read_wire_nonblocking(channel, data, len, &cond);
>  
> -if (ret == -1) {
> -if (cond != 0) {
> -// TODO: should use 
> g_pollable_input/output_stream_create_source() ?
> -g_coroutine_socket_wait(&c->coroutine, c->sock, cond);
> -goto reread;
> -} else {
> +if (ret == -1) {
> +if (cond != 0) {
> +// TODO: should use 
> g_pollable_input/output_stream_create_source() ?
> +g_coroutine_socket_wait(&c->coroutine, c->sock, cond);
> +continue;
> +} else {
> +c->has_error = TRUE;
> +return -errno;
> +}
> +}
> +if (ret == 0) {
> +CHANNEL_DEBUG(channel, "Closing the connection: 
> spice_channel_read() - ret=0");
>  c->has_error = TRUE;
> -return -errno;
> +return 0;
>  }
> -}
> -if (ret == 0) {
> -CHANNEL_DEBUG(channel, "Closing the connection: spice_channel_read() 
> - ret=0");
> -c->has_error = TRUE;
> -return 0;
> -}
>  
> -return ret;
> +return ret;
> +}
>  }
>  
>  #ifdef HAVE_SASL
> -- 
> 2.9.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [spice-gtk v4 3/6] spice_channel_read_wire: prefer while(TRUE) instead of goto

[Victor Toso]

From: Victor Toso 

Although this is likely to be a single loop iteration based on the
implementation of g_coroutine_socket_wait(), using goto to reiterate
in the code should be avoided based on spice style recommendation.

This also make it easier to add follow up changes that can increase
the loop iterations.

This patch changes:
 * The reread label with a while(TRUE);
 * The goto keyword with continue;

All other changes are only related to new indentation.

Signed-off-by: Victor Toso 
---
 src/spice-channel.c | 35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/src/spice-channel.c b/src/spice-channel.c
index 999c615..f2d1b8a 100644
--- a/src/spice-channel.c
+++ b/src/spice-channel.c
@@ -1051,29 +1051,30 @@ static int spice_channel_read_wire(SpiceChannel 
*channel, void *data, size_t len
 GIOCondition cond;
 gssize ret;
 
-reread:
+while (TRUE) {
 
-if (c->has_error) return 0; /* has_error is set by disconnect(), return no 
error */
+if (c->has_error) return 0; /* has_error is set by disconnect(), 
return no error */
 
-ret = spice_channel_read_wire_nonblocking(channel, data, len, &cond);
+ret = spice_channel_read_wire_nonblocking(channel, data, len, &cond);
 
-if (ret == -1) {
-if (cond != 0) {
-// TODO: should use g_pollable_input/output_stream_create_source() 
?
-g_coroutine_socket_wait(&c->coroutine, c->sock, cond);
-goto reread;
-} else {
+if (ret == -1) {
+if (cond != 0) {
+// TODO: should use 
g_pollable_input/output_stream_create_source() ?
+g_coroutine_socket_wait(&c->coroutine, c->sock, cond);
+continue;
+} else {
+c->has_error = TRUE;
+return -errno;
+}
+}
+if (ret == 0) {
+CHANNEL_DEBUG(channel, "Closing the connection: 
spice_channel_read() - ret=0");
 c->has_error = TRUE;
-return -errno;
+return 0;
 }
-}
-if (ret == 0) {
-CHANNEL_DEBUG(channel, "Closing the connection: spice_channel_read() - 
ret=0");
-c->has_error = TRUE;
-return 0;
-}
 
-return ret;
+return ret;
+}
 }
 
 #ifdef HAVE_SASL
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Multi Console

[Pavel Grunt]

On Wed, 2017-03-01 at 10:21 +0100, Christian Rilke wrote:
> Hi,
>  
> first think i have to say is THANK YOU! Spice is the best think
> happened to the qmeu community since we need graphical consoles.
>  
> I just have a short question about multiple console feature. I read
> that is still experimental? Is this still true? I found out that i
> need SPICE_DEBUG_ALLOW_MC=1 to get it working.
> Are there any more concrete plants to improve this feature? We use
> this daily. The most time we have no trouble but sometimes its
> buggy. Specially if some change the size of he spice window.

It is problematic - if one changes the size, the change is transferred
to other users. Sometimes there can be a race - for instance when one
uses virt-manager as a client - it has a fixed size, so it keeps
sending a size request matching its size (and possibly overwriting
request from other clients).

A solution may be to accept size request only from one client (or
agent messages in general)


If you find some bugs, please report them.

Thanks,
Pavel

>  
> Cheers,
> Chris
> 
> 
> Diese E-
> Mail wurde von einem automatischen Virenscanner überprüft und für vi
> renfrei befunden.
> Es kann jedoch nicht ausgeschlossen werden, dass Mails mit noch unbe
> kannten Viren verseucht sind.
> IBIX Informationssysteme GmbH übernimmt keine Haftung für Schäden du
> rch Virenbefall.
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v3 0/6] spice-channel: read/flush wire functions

[Victor Toso]

Hi,

On Thu, Mar 02, 2017 at 02:28:37PM +0100, Christophe Fergeau wrote:
> On Thu, Mar 02, 2017 at 02:05:21PM +0100, Victor Toso wrote:
> > > and the while (TRUE) is equally odd if you ask me (mostly because you
> > > said it would loop at most once anyway).
> >
> > The iteration should happen only once because g_coroutine_socket_wait()
> > does wait G_IO_IN/G_IO_OUT. Its very unlikely that after
> > g_coroutine_socket_wait() returns, we can't read or write.
> >
> > Still, that's not odd. Not odd at all. Unless `goto reread` give us some
> > performance gain here, I can't see goto label being preferred to
> > while(1).
>
> Yes, in both cases it's not really obvious how many iterations there's
> going to be. Just more subtle with the goto than with the while :)

I would say more hidden with goto

>
> > > I guess I could live with it with a slightly better changelog, and
> > > maybe a comment indicating this is not really a loop.
> >
> > I can't see a reason to improve the commit log if you don't agree with
> > the changes and I don't really intend to keep discussing over this that
> > seems more a personal preference thing. I might be completely wrong in
> > the end :)
>
> You seem to prefer the while(TRUE), and I don't care that strongly, and
> I really think the commit log can be slightly better. "using goto to
> reiterate in the code should be avoided." reads as if this was a golden
> rule (coming from where?) never ever to be broken.

Right, I don't mean it as a golden rule.

> I'd just state that this makes the code follow the recommendations
> from SPICE coding style.

Okay, I'll improve it and resend.

> > Still, IMO I see an improvement while interacting with this code later
> > on. Maybe I should not have sent this to soon but I'm trying to avoid
> > huge patch series whenever I can. See this 'wip-qos' patch in current
> > master [1] and with this series [2].
> >
> > [1] 
> > https://gitlab.com/victortoso/spice-gtk/commit/9c68d7875beafbc49df4dc1b8c58a490fbc355b8?view=parallel
> > [2] 
> > https://gitlab.com/victortoso/spice-gtk/commit/326528c9674dbeb765bb50f6d0b729f8a2b45c57?view=parallel
>
> Thanks, this kind of context can be part of the cover letter.
>
> Christophe

Surely, I'll try to keep that in mind in the future.

toso


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH v4] Switch over to using keycodemapdb submodule

[Pavel Grunt]

On Thu, 2017-03-02 at 10:07 +, Daniel P. Berrange wrote:
> Consume the keymaps.csv file from a git submodule instead of having
> a private copy. This makes it easier to ensure all users of the
> keymap
> (libvirt, gtk-vnc, spice-gtk, and eventually QEMU) to have a
> consistent
> set of data.
> 
> Signed-off-by: Daniel P. Berrange 
Acked-by: Pavel Grunt 
> ---
> 
> Changed in v4:
> 
>   - Use correct submodule commit to fix OSX keymaps
> 
>  .gitmodules   |   3 +
>  configure.ac  |  11 --
>  src/Makefile.am   |  30 ++--
>  src/keycodemapdb  |   1 +
>  src/keymap-gen.pl | 214 ---
>  src/keymaps.csv   | 511 -
> -
>  6 files changed, 17 insertions(+), 753 deletions(-)
>  create mode 16 src/keycodemapdb
>  delete mode 100755 src/keymap-gen.pl
>  delete mode 100644 src/keymaps.csv
> 
> diff --git a/.gitmodules b/.gitmodules
> index 0c618ee..82467e4 100644
> --- a/.gitmodules
> +++ b/.gitmodules
> @@ -1,3 +1,6 @@
>  [submodule "spice-common"]
>   path = spice-common
>   url = ../spice-common
> +[submodule "src/keycodemapdb"]
> + path = src/keycodemapdb
> + url = https://gitlab.com/keycodemap/keycodemapdb.git
> diff --git a/configure.ac b/configure.ac
> index 463fbe0..763d14b 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -86,17 +86,6 @@ AC_SUBST(SPICE_GTK_MICRO_VERSION)
>  dnl
> 
> =
>  dnl Chek optional features
>  
> -srcdir="$(dirname $0)"
> -if test ! -e "$srcdir/src/vncdisplaykeymap_osx2xtkbd.c"; then
> -  AC_MSG_CHECKING([for Text::CSV Perl module])
> -  perl -MText::CSV -e "" >/dev/null 2>&1
> -  if test $? -ne 0 ; then
> -AC_MSG_RESULT([not found])
> -AC_MSG_ERROR([Text::CSV Perl module is required to compile this
> package])
> -  fi
> -  AC_MSG_RESULT([found])
> -fi
> -
>  SPICE_GLIB_REQUIRES=""
>  SPICE_GTK_REQUIRES=""
>  
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 7542fac..594c0de 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -26,14 +26,13 @@ GLIBGENS =
> \
>   spice-widget-enums.h\
>   $(NULL)
>  
> -CLEANFILES = $(GLIBGENS)
> +CLEANFILES = $(GLIBGENS) $(KEYMAPS)
>  BUILT_SOURCES = $(GLIBGENS) $(KEYMAPS)
>  
>  EXTRA_DIST = \
> - $(KEYMAPS)  \
>   decode-glz-tmpl.c   \
> - keymap-gen.pl   \
> - keymaps.csv \
> + $(KEYMAP_CSV)   \
> + $(KEYMAP_GEN)   \
>   map-file\
>   spice-glib-sym-file \
>   spice-gtk-sym-file  \
> @@ -66,7 +65,8 @@ GTK_SYMBOLS_LDFLAGS = -export-symbols
> ${srcdir}/spice-gtk-sym-file
>  GTK_SYMBOLS_FILE = spice-gtk-sym-file
>  endif
>  
> -KEYMAP_GEN = $(srcdir)/keymap-gen.pl
> +KEYMAP_GEN = keycodemapdb/tools/keymap-gen
> +KEYMAP_CSV = keycodemapdb/data/keymaps.csv
>  
>  SPICE_COMMON_CPPFLAGS =  
> \
>   -DSPICE_COMPILATION 
> \
> @@ -483,32 +483,28 @@ spice-widget-enums.h: spice-widget.h
>  
>  
>  vncdisplaykeymap.c: $(KEYMAPS)
> +$(KEYMAPS): $(srcdir)/$(KEYMAP_GEN) $(srcdir)/$(KEYMAP_CSV)
>  
> -$(KEYMAPS): $(KEYMAP_GEN) keymaps.csv
> -
> -# Note despite being autogenerated these are not part of
> CLEANFILES, they
> -# are actually a part of EXTRA_DIST to avoid the need for
> perl(Text::CSV) by
> -# end users
>  vncdisplaykeymap_xorgevdev2xtkbd.c:
> - $(AM_V_GEN)$(KEYMAP_GEN) $(srcdir)/keymaps.csv xorgevdev
> xtkbd > $@ || rm $@
> + $(AM_V_GEN)$(PYTHON) $(srcdir)/$(KEYMAP_GEN) --lang glib2
> --varname keymap_xorgevdev2xtkbd code-map $(srcdir)/$(KEYMAP_CSV)
> xorgevdev xtkbd > $@ || rm $@
>  
>  vncdisplaykeymap_xorgkbd2xtkbd.c:
> - $(AM_V_GEN)$(KEYMAP_GEN) $(srcdir)/keymaps.csv xorgkbd
> xtkbd > $@ || rm $@
> + $(AM_V_GEN)$(PYTHON) $(srcdir)/$(KEYMAP_GEN) --lang glib2
> --varname keymap_xorgkbd2xtkbd code-map $(srcdir)/$(KEYMAP_CSV)
> xorgkbd xtkbd > $@ || rm $@
>  
>  vncdisplaykeymap_xorgxquartz2xtkbd.c:
> - $(AM_V_GEN)$(KEYMAP_GEN) $(srcdir)/keymaps.csv xorgxquartz
> xtkbd > $@ || rm $@
> + $(AM_V_GEN)$(PYTHON) $(srcdir)/$(KEYMAP_GEN) --lang glib2
> --varname keymap_xorgxquartz2xtkbd code-map $(srcdir)/$(KEYMAP_CSV)
> xorgxquartz xtkbd > $@ || rm $@
>  
>  vncdisplaykeymap_xorgxwin2xtkbd.c:
> - $(AM_V_GEN)$(KEYMAP_GEN) $(srcdir)/keymaps.csv xorgxwin
> xtkbd > $@ || rm $@
> + $(AM_V_GEN)$(PYTHON) $(srcdir)/$(KEYMAP_GEN) --lang glib2
> --varname keymap_xorgxwin2xtkbd code-map $(srcdir)/$(KEYMAP_CSV)
> xorgxwin xtkbd > $@ || rm $@
>  
>  vncdisplaykeymap_osx2xtkbd.c:
> - $(AM_V_GEN)$(KEYMAP_GEN) $(srcdir)/keymaps.csv osx xtkbd >
> $@ || rm $@
> + $(AM_V_GEN)$(PYTHON) $(srcdir)/$(KEYMAP_GEN) 

[Spice-devel] [PATCH spice-server 2/3] tests: Move some specific GLib compatibility to compatibility file

[Frediano Ziglio]

Signed-off-by: Frediano Ziglio 
---
 server/glib-compat.h   |  8 
 server/tests/test-codecs-parsing.c |  6 +-
 server/tests/test-leaks.c  |  7 +--
 server/tests/test-options.c|  7 +--
 server/tests/test-stat-file.c  | 10 +-
 5 files changed, 12 insertions(+), 26 deletions(-)

diff --git a/server/glib-compat.h b/server/glib-compat.h
index 9d75701..557e13e 100644
--- a/server/glib-compat.h
+++ b/server/glib-compat.h
@@ -72,4 +72,12 @@ void g_test_expect_message(const gchar *log_domain, 
GLogLevelFlags log_level,
const gchar *pattern);
 #endif
 
+/* GLIB_CHECK_VERSION(2, 40, 0) */
+#ifndef g_assert_nonnull
+#define g_assert_nonnull g_assert
+#endif
+#ifndef g_assert_null
+#define g_assert_null(ptr) g_assert((ptr) == NULL)
+#endif
+
 #endif /* GLIB_COMPAT_H_ */
diff --git a/server/tests/test-codecs-parsing.c 
b/server/tests/test-codecs-parsing.c
index 5af2e5d..571d8ab 100644
--- a/server/tests/test-codecs-parsing.c
+++ b/server/tests/test-codecs-parsing.c
@@ -16,13 +16,9 @@
License along with this library; if not, see .
 */
 #include 
-#include 
 #include 
 
-/* GLIB_CHECK_VERSION(2, 40, 0) */
-#ifndef g_assert_nonnull
-#define g_assert_nonnull g_assert
-#endif
+#include "glib-compat.h"
 
 static void codecs_good(void)
 {
diff --git a/server/tests/test-leaks.c b/server/tests/test-leaks.c
index b8521f4..21ffd5c 100644
--- a/server/tests/test-leaks.c
+++ b/server/tests/test-leaks.c
@@ -16,16 +16,11 @@
License along with this library; if not, see .
 */
 #include 
-#include 
 #include 
 
+#include "glib-compat.h"
 #include "basic-event-loop.h"
 
-/* GLIB_CHECK_VERSION(2, 40, 0) */
-#ifndef g_assert_nonnull
-#define g_assert_nonnull g_assert
-#endif
-
 static void leaks(void)
 {
 int result;
diff --git a/server/tests/test-options.c b/server/tests/test-options.c
index 0cfd4b3..2c612c3 100644
--- a/server/tests/test-options.c
+++ b/server/tests/test-options.c
@@ -16,16 +16,11 @@
License along with this library; if not, see .
 */
 #include 
-#include 
 #include 
 
+#include "glib-compat.h"
 #include "basic-event-loop.h"
 
-/* GLIB_CHECK_VERSION(2, 40, 0) */
-#ifndef g_assert_nonnull
-#define g_assert_nonnull g_assert
-#endif
-
 static void agent_options(void)
 {
 SpiceCoreInterface *core ;
diff --git a/server/tests/test-stat-file.c b/server/tests/test-stat-file.c
index 40cf37d..502aadd 100644
--- a/server/tests/test-stat-file.c
+++ b/server/tests/test-stat-file.c
@@ -19,19 +19,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
+#include "glib-compat.h"
 #include "stat-file.h"
 
-/* GLIB_CHECK_VERSION(2, 40, 0) */
-#ifndef g_assert_nonnull
-#define g_assert_nonnull g_assert
-#endif
-#ifndef g_assert_null
-#define g_assert_null(ptr) g_assert((ptr) == NULL)
-#endif
-
 static void stat_file(void)
 {
 RedStatFile *stat_file;
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server 3/3] tests: Reuse GLib compatibility code

[Frediano Ziglio]

Instead of disabling the code use the compatibility functions.

Signed-off-by: Frediano Ziglio 
---
 server/tests/test-codecs-parsing.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/server/tests/test-codecs-parsing.c 
b/server/tests/test-codecs-parsing.c
index 571d8ab..838a80c 100644
--- a/server/tests/test-codecs-parsing.c
+++ b/server/tests/test-codecs-parsing.c
@@ -46,8 +46,9 @@ static void codecs_good(void)
 }
 
 /* g_test_expect_message is available since Glib 2.34 */
-#if GLIB_CHECK_VERSION(2, 34, 0)
+#ifdef G_GNUC_BEGIN_IGNORE_DEPRECATIONS
 G_GNUC_BEGIN_IGNORE_DEPRECATIONS
+#endif
 static void codecs_bad(void)
 {
 guint i;
@@ -137,6 +138,7 @@ static void codecs_bad(void)
 
 spice_server_destroy(server);
 }
+#ifdef G_GNUC_BEGIN_IGNORE_DEPRECATIONS
 G_GNUC_END_IGNORE_DEPRECATIONS
 #endif
 
@@ -145,9 +147,7 @@ int main(int argc, char *argv[])
 g_test_init(&argc, &argv, NULL);
 
 g_test_add_func("/server/codecs-good", codecs_good);
-#if GLIB_CHECK_VERSION(2, 34, 0)
 g_test_add_func("/server/codecs-bad", codecs_bad);
-#endif
 
 return g_test_run();
 }
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server 1/3] tests: Move some glib compatibility code to a separate file

[Frediano Ziglio]

Allow to reuse this code in other tests.

Signed-off-by: Frediano Ziglio 
---
 server/glib-compat.h|   9 
 server/tests/Makefile.am|   1 +
 server/tests/test-glib-compat.c | 112 
 server/tests/test-vdagent.c |  92 +
 4 files changed, 123 insertions(+), 91 deletions(-)
 create mode 100644 server/tests/test-glib-compat.c

diff --git a/server/glib-compat.h b/server/glib-compat.h
index 50a0783..9d75701 100644
--- a/server/glib-compat.h
+++ b/server/glib-compat.h
@@ -63,4 +63,13 @@ g_queue_remove_boolean(GQueue *queue, gconstpointer data)
 #define g_queue_remove g_queue_remove_boolean
 #endif
 
+#if !GLIB_CHECK_VERSION(2, 34, 0)
+void g_test_assert_expected_messages_internal(const char *domain,
+  const char *file, int line, 
const char *func);
+#define g_test_assert_expected_messages() \
+g_test_assert_expected_messages_internal (G_LOG_DOMAIN, __FILE__, 
__LINE__, G_STRFUNC)
+void g_test_expect_message(const gchar *log_domain, GLogLevelFlags log_level,
+   const gchar *pattern);
+#endif
+
 #endif /* GLIB_COMPAT_H_ */
diff --git a/server/tests/Makefile.am b/server/tests/Makefile.am
index dd04834..ca70e22 100644
--- a/server/tests/Makefile.am
+++ b/server/tests/Makefile.am
@@ -25,6 +25,7 @@ libtest_a_SOURCES =   \
basic-event-loop.h  \
test-display-base.c \
test-display-base.h \
+   test-glib-compat.c  \
$(NULL)
 
 LDADD =\
diff --git a/server/tests/test-glib-compat.c b/server/tests/test-glib-compat.c
new file mode 100644
index 000..9b47dc6
--- /dev/null
+++ b/server/tests/test-glib-compat.c
@@ -0,0 +1,112 @@
+/* -*- Mode: C; c-basic-offset: 4; indent-tabs-mode: nil -*- */
+/*
+   Copyright (C) 2017 Red Hat, Inc.
+
+   This library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   This library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with this library; if not, see .
+*/
+
+#include 
+
+#include "glib-compat.h"
+
+#if !GLIB_CHECK_VERSION(2, 34, 0)
+
+/* The code in this #ifdef block is taken from glib and is licensed under the
+ * GNU Lesser General Public License version 2 or later.
+ *
+ * Copyright (C) 1995-1997  Peter Mattis, Spencer Kimball and Josh MacDonald
+ * Modified by the GLib Team and others 1997-2000.  See GLib AUTHORS
+ * file for a list of people on the GLib Team.
+ */
+
+typedef struct {
+gchar *log_domain;
+GLogLevelFlags log_level;
+gchar *pattern;
+} GTestExpectedMessage;
+
+static GSList *expected_messages = NULL;
+
+static gboolean fatal_log_filter(const gchar *log_domain,
+ GLogLevelFlags log_level,
+ const gchar *msg,
+ gpointer user_data)
+{
+GTestExpectedMessage *expected = expected_messages->data;
+
+if ((g_strcmp0(expected->log_domain, log_domain) == 0)
+&& ((log_level & expected->log_level) == expected->log_level)
+&& (g_pattern_match_simple(expected->pattern, msg))) {
+expected_messages = g_slist_delete_link(expected_messages,
+expected_messages);
+g_free (expected->log_domain);
+g_free (expected->pattern);
+g_free (expected);
+
+return FALSE;
+}
+return TRUE;
+}
+
+void
+g_test_assert_expected_messages_internal (const char *domain,
+  const char *file,
+  int line,
+  const char *func)
+{
+  if (expected_messages)
+{
+  GTestExpectedMessage *expected;
+  gchar *message;
+
+  expected = expected_messages->data;
+
+  message = g_strdup_printf ("Did not see expected message %s: %s",
+ expected->log_domain ? expected->log_domain : 
"**",
+ expected->pattern);
+  g_error ("%s", message);
+  g_free (message);
+}
+}
+
+#define g_test_assert_expected_messages() 
g_test_assert_expected_messages_internal (G_LOG_DOMAIN, __FILE__, __LINE__, 
G_STRFUNC)
+
+void
+g_test_expect_message (const gchar*log_domain,
+   GLogLeve

Re: [Spice-devel] [PATCH spice-gtk v2] spicy: Add dialog for precise resizing

[Victor Toso]

Hi,

On Thu, Mar 02, 2017 at 02:05:06PM +0100, Pavel Grunt wrote:
> It helps when testing whether the guest resizes to requested resolution

Yes it does, LGTM
Acked-by: Victor Toso 

> ---
>  tools/spicy.c | 62 
> +++
>  1 file changed, 62 insertions(+)
> 
> diff --git a/tools/spicy.c b/tools/spicy.c
> index ce6b40b..c47e208 100644
> --- a/tools/spicy.c
> +++ b/tools/spicy.c
> @@ -566,6 +566,60 @@ static void keyboard_grab_cb(GtkWidget *widget, gint 
> grabbed, gpointer data)
>  }
>  }
>  
> +static void menu_cb_resize_to(GtkAction *action G_GNUC_UNUSED,
> +  gpointer data)
> +{
> +SpiceWindow *win = data;
> +GtkWidget *dialog;
> +GtkWidget *spin_width, *spin_height, *spin_x, *spin_y;
> +GtkGrid *grid;
> +gint width, height;
> +dialog = gtk_dialog_new_with_buttons("Resize guest to",
> + GTK_WINDOW(win->toplevel),
> + GTK_DIALOG_DESTROY_WITH_PARENT,
> + "_Apply",
> + GTK_RESPONSE_APPLY,
> + "_Cancel",
> + GTK_RESPONSE_CANCEL,
> + NULL);
> +
> +spin_width = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
> +spin_height = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
> +spin_x = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
> +spin_y = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
> +
> +gtk_widget_get_preferred_width(win->spice, NULL, &width);
> +gtk_widget_get_preferred_height(win->spice, NULL, &height);
> +
> +gtk_spin_button_set_value(GTK_SPIN_BUTTON(spin_width), width);
> +gtk_spin_button_set_value(GTK_SPIN_BUTTON(spin_height), height);
> +
> +grid = GTK_GRID(gtk_grid_new());
> +
> gtk_container_add(GTK_CONTAINER(gtk_dialog_get_content_area(GTK_DIALOG(dialog))),
>  GTK_WIDGET(grid));
> +gtk_grid_attach(grid, gtk_label_new("Resize the guest display:"), 0, 0, 
> 2, 1);
> +gtk_grid_attach(grid, gtk_label_new("width:"), 0, 2, 1, 1);
> +gtk_grid_attach(grid, spin_width, 1, 2, 1, 1);
> +gtk_grid_attach(grid, gtk_label_new("height:"), 0, 3, 1, 1);
> +gtk_grid_attach(grid, spin_height, 1, 3, 1, 1);
> +gtk_grid_attach(grid, gtk_label_new("x:"), 0, 4, 1, 1);
> +gtk_grid_attach(grid, spin_x, 1, 4, 1, 1);
> +gtk_grid_attach(grid, gtk_label_new("y:"), 0, 5, 1, 1);
> +gtk_grid_attach(grid, spin_y, 1, 5, 1, 1);
> +
> +gtk_widget_show_all(dialog);
> +if (gtk_dialog_run(GTK_DIALOG (dialog)) == GTK_RESPONSE_APPLY) {
> +spice_main_update_display_enabled(win->conn->main, win->id + 
> win->monitor_id, TRUE, FALSE);
> +spice_main_set_display(win->conn->main,
> +   win->id + win->monitor_id,
> +   
> gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_x)),
> +   
> gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_y)),
> +   
> gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_width)),
> +   
> gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_height)));
> +spice_main_send_monitor_config(win->conn->main);
> +}
> +gtk_widget_destroy(dialog);
> +}
> +
>  static void restore_configuration(SpiceWindow *win)
>  {
>  gboolean state;
> @@ -692,6 +746,11 @@ static const GtkActionEntry entries[] = {
>  .callback= G_CALLBACK(menu_cb_fullscreen),
>  .accelerator = "F11",
>  },{
> +.name= "ResizeTo",
> +.label   = "_Resize to",
> +.callback= G_CALLBACK(menu_cb_resize_to),
> +.accelerator = "",
> +},{
>  #ifdef USE_SMARTCARD
>   .name= "InsertSmartcard",
>   .label   = "_Insert Smartcard",
> @@ -905,6 +964,9 @@ static char ui_xml[] =
>  "\n"
>  "\n"
>  "\n"
> +"\n"
> +"\n"
> +"\n"
>  "  \n"
>  "\n";
>  
> -- 
> 2.12.0
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v3 0/6] spice-channel: read/flush wire functions

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 02:05:21PM +0100, Victor Toso wrote:
> > and the while (TRUE) is equally odd if you ask me (mostly because you
> > said it would loop at most once anyway).
> 
> The iteration should happen only once because g_coroutine_socket_wait()
> does wait G_IO_IN/G_IO_OUT. Its very unlikely that after
> g_coroutine_socket_wait() returns, we can't read or write.
> 
> Still, that's not odd. Not odd at all. Unless `goto reread` give us some
> performance gain here, I can't see goto label being preferred to
> while(1).

Yes, in both cases it's not really obvious how many iterations there's
going to be. Just more subtle with the goto than with the while :)

> > I guess I could live with it with a slightly better changelog, and
> > maybe a comment indicating this is not really a loop.
> 
> I can't see a reason to improve the commit log if you don't agree with
> the changes and I don't really intend to keep discussing over this that
> seems more a personal preference thing. I might be completely wrong in
> the end :)

You seem to prefer the while(TRUE), and I don't care that strongly, and
I really think the commit log can be slightly better. "using goto to
reiterate in the code should be avoided." reads as if this was a golden
rule (coming from where?) never ever to be broken. I'd just state that
this makes the code follow the recommendations from SPICE coding style.


> 
> Still, IMO I see an improvement while interacting with this code later
> on. Maybe I should not have sent this to soon but I'm trying to avoid
> huge patch series whenever I can. See this 'wip-qos' patch in current
> master [1] and with this series [2].
> 
> [1] 
> https://gitlab.com/victortoso/spice-gtk/commit/9c68d7875beafbc49df4dc1b8c58a490fbc355b8?view=parallel
> [2] 
> https://gitlab.com/victortoso/spice-gtk/commit/326528c9674dbeb765bb50f6d0b729f8a2b45c57?view=parallel

Thanks, this kind of context can be part of the cover letter.

Christophe


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v3 0/6] spice-channel: read/flush wire functions

[Victor Toso]

Hi,

On Thu, Mar 02, 2017 at 01:35:32PM +0100, Christophe Fergeau wrote:
> The code is preexisting

Hm, so I should avoid reworking code that does not fit in newer
style or standards?

> it's arguably error handling

Agreed

> and the while (TRUE) is equally odd if you ask me (mostly because you
> said it would loop at most once anyway).

The iteration should happen only once because g_coroutine_socket_wait()
does wait G_IO_IN/G_IO_OUT. Its very unlikely that after
g_coroutine_socket_wait() returns, we can't read or write.

Still, that's not odd. Not odd at all. Unless `goto reread` give us some
performance gain here, I can't see goto label being preferred to
while(1).

In college I would lose valuable points choosing one over the other.

> I guess I could live with it with a slightly better changelog, and
> maybe a comment indicating this is not really a loop.

I can't see a reason to improve the commit log if you don't agree with
the changes and I don't really intend to keep discussing over this that
seems more a personal preference thing. I might be completely wrong in
the end :)

Still, IMO I see an improvement while interacting with this code later
on. Maybe I should not have sent this to soon but I'm trying to avoid
huge patch series whenever I can. See this 'wip-qos' patch in current
master [1] and with this series [2].

[1] 
https://gitlab.com/victortoso/spice-gtk/commit/9c68d7875beafbc49df4dc1b8c58a490fbc355b8?view=parallel
[2] 
https://gitlab.com/victortoso/spice-gtk/commit/326528c9674dbeb765bb50f6d0b729f8a2b45c57?view=parallel

Cheers,
toso


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk v2] spicy: Add dialog for precise resizing

[Pavel Grunt]

It helps when testing whether the guest resizes to requested resolution
---
 tools/spicy.c | 62 +++
 1 file changed, 62 insertions(+)

diff --git a/tools/spicy.c b/tools/spicy.c
index ce6b40b..c47e208 100644
--- a/tools/spicy.c
+++ b/tools/spicy.c
@@ -566,6 +566,60 @@ static void keyboard_grab_cb(GtkWidget *widget, gint 
grabbed, gpointer data)
 }
 }
 
+static void menu_cb_resize_to(GtkAction *action G_GNUC_UNUSED,
+  gpointer data)
+{
+SpiceWindow *win = data;
+GtkWidget *dialog;
+GtkWidget *spin_width, *spin_height, *spin_x, *spin_y;
+GtkGrid *grid;
+gint width, height;
+dialog = gtk_dialog_new_with_buttons("Resize guest to",
+ GTK_WINDOW(win->toplevel),
+ GTK_DIALOG_DESTROY_WITH_PARENT,
+ "_Apply",
+ GTK_RESPONSE_APPLY,
+ "_Cancel",
+ GTK_RESPONSE_CANCEL,
+ NULL);
+
+spin_width = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
+spin_height = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
+spin_x = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
+spin_y = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
+
+gtk_widget_get_preferred_width(win->spice, NULL, &width);
+gtk_widget_get_preferred_height(win->spice, NULL, &height);
+
+gtk_spin_button_set_value(GTK_SPIN_BUTTON(spin_width), width);
+gtk_spin_button_set_value(GTK_SPIN_BUTTON(spin_height), height);
+
+grid = GTK_GRID(gtk_grid_new());
+
gtk_container_add(GTK_CONTAINER(gtk_dialog_get_content_area(GTK_DIALOG(dialog))),
 GTK_WIDGET(grid));
+gtk_grid_attach(grid, gtk_label_new("Resize the guest display:"), 0, 0, 2, 
1);
+gtk_grid_attach(grid, gtk_label_new("width:"), 0, 2, 1, 1);
+gtk_grid_attach(grid, spin_width, 1, 2, 1, 1);
+gtk_grid_attach(grid, gtk_label_new("height:"), 0, 3, 1, 1);
+gtk_grid_attach(grid, spin_height, 1, 3, 1, 1);
+gtk_grid_attach(grid, gtk_label_new("x:"), 0, 4, 1, 1);
+gtk_grid_attach(grid, spin_x, 1, 4, 1, 1);
+gtk_grid_attach(grid, gtk_label_new("y:"), 0, 5, 1, 1);
+gtk_grid_attach(grid, spin_y, 1, 5, 1, 1);
+
+gtk_widget_show_all(dialog);
+if (gtk_dialog_run(GTK_DIALOG (dialog)) == GTK_RESPONSE_APPLY) {
+spice_main_update_display_enabled(win->conn->main, win->id + 
win->monitor_id, TRUE, FALSE);
+spice_main_set_display(win->conn->main,
+   win->id + win->monitor_id,
+   
gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_x)),
+   
gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_y)),
+   
gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_width)),
+   
gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_height)));
+spice_main_send_monitor_config(win->conn->main);
+}
+gtk_widget_destroy(dialog);
+}
+
 static void restore_configuration(SpiceWindow *win)
 {
 gboolean state;
@@ -692,6 +746,11 @@ static const GtkActionEntry entries[] = {
 .callback= G_CALLBACK(menu_cb_fullscreen),
 .accelerator = "F11",
 },{
+.name= "ResizeTo",
+.label   = "_Resize to",
+.callback= G_CALLBACK(menu_cb_resize_to),
+.accelerator = "",
+},{
 #ifdef USE_SMARTCARD
.name= "InsertSmartcard",
.label   = "_Insert Smartcard",
@@ -905,6 +964,9 @@ static char ui_xml[] =
 "\n"
 "\n"
 "\n"
+"\n"
+"\n"
+"\n"
 "  \n"
 "\n";
 
-- 
2.12.0

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v3 0/6] spice-channel: read/flush wire functions

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 11:46:34AM +0100, Victor Toso wrote:
> Hi,
> 
> Thanks for taking a look :)
> 
> On Thu, Mar 02, 2017 at 10:59:12AM +0100, Christophe Fergeau wrote:
> > On Thu, Mar 02, 2017 at 10:23:45AM +0100, Victor Toso wrote:
> > > Hi,
> > >
> > > On Tue, Feb 28, 2017 at 12:21:45PM +0100, Victor Toso wrote:
> > > > From: Victor Toso 
> > > >
> > > > Hi,
> > > >
> > > > v2->v3:
> > > > * Breaking spice_channel_read_wire() into smaller changes. (teuf)
> > > >
> > > > v2: 
> > > > https://lists.freedesktop.org/archives/spice-devel/2017-February/035455.html
> > > > v1: 
> > > > https://lists.freedesktop.org/archives/spice-devel/2017-February/035446.html
> > > >
> > > > Cheers,
> > > >
> > > > Victor Toso (6):
> > > >   spice-channel: move out non blocking logic of _read_wire()
> > > >   spice-channel: move out non blocking logic of _flush_wire()
> > > >   spice_channel_read_wire: prefer while(TRUE) instead of goto
> > > >   spice_channel_read_wire: move variables to internal scope
> > >
> > > Any feedback on 3/6 and 4/6 ? I don't mind dropping the 5/6 and 6/6
> > > patches at all. They don't bring much benefit and it might be just
> > > personal preference.
> >
> > I was looking at this series yesterday, and I'm not really convinced it
> > brings much, the while (TRUE) which is iterated once at most is as weird
> > as the goto, before the patch the code is
> 
> We should only use goto to deal with errors or exceptions. Not sure why
> here would be an exception.
> 
> https://www.spice-space.org/spice-project-coding-style-and-coding-conventions.html

The code is preexisting, it's arguably error handling, and the while
(TRUE) is equally odd if you ask me (mostly because you said it would
loop at most once anyway). I guess I could live with it with a slightly
better changelog, and maybe a comment indicating this is not really a
loop.

Christophe


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server v4 3/3] red-channel: Use RedChannelCapabilities directly to pass capabilities

[Frediano Ziglio]

For each channel there are two set of capabilities, one
for the common ones and one for the specific ones.
A single set were almost always passed using 2 arguments,
a number of elements and an array but then before using
these were converted to a GArray.
Use a single structure (already available) to pass all
channel capabilites using a single argument.

Signed-off-by: Frediano Ziglio 
---
 server/cursor-channel-client.c| 22 ++
 server/cursor-channel-client.h|  4 +--
 server/cursor-channel.c   |  6 ++--
 server/cursor-channel.h   |  3 +-
 server/dcc.c  | 22 ++
 server/dcc.h  |  5 +---
 server/inputs-channel-client.c| 23 ++-
 server/inputs-channel-client.h|  5 +---
 server/inputs-channel.c   |  7 ++---
 server/main-channel-client.c  | 22 ++
 server/main-channel-client.h  |  3 +-
 server/main-channel.c |  7 ++---
 server/main-channel.h |  4 +--
 server/red-channel-client.c   | 62 +--
 server/red-channel-client.h   |  3 +-
 server/red-channel.c  | 19 
 server/red-channel.h  |  7 ++---
 server/red-qxl.c  | 24 ---
 server/red-qxl.h  | 10 ++-
 server/red-worker.c   | 11 +++
 server/reds.c | 41 ++
 server/smartcard-channel-client.c | 22 ++
 server/smartcard-channel-client.h |  3 +-
 server/smartcard.c|  6 ++--
 server/sound.c| 37 +--
 server/spicevmc.c | 11 ---
 26 files changed, 94 insertions(+), 295 deletions(-)

diff --git a/server/cursor-channel-client.c b/server/cursor-channel-client.c
index 56efd1e..1a05f73 100644
--- a/server/cursor-channel-client.c
+++ b/server/cursor-channel-client.c
@@ -93,21 +93,9 @@ void cursor_channel_client_migrate(RedChannelClient *rcc)
 
 CursorChannelClient* cursor_channel_client_new(CursorChannel *cursor, 
RedClient *client, RedsStream *stream,
int mig_target,
-   uint32_t *common_caps, int 
num_common_caps,
-   uint32_t *caps, int num_caps)
+   RedChannelCapabilities *caps)
 {
 CursorChannelClient *rcc;
-GArray *common_caps_array = NULL, *caps_array = NULL;
-
-if (common_caps) {
-common_caps_array = g_array_sized_new(FALSE, FALSE, sizeof 
(*common_caps),
-  num_common_caps);
-g_array_append_vals(common_caps_array, common_caps, num_common_caps);
-}
-if (caps) {
-caps_array = g_array_sized_new(FALSE, FALSE, sizeof (*caps), num_caps);
-g_array_append_vals(caps_array, caps, num_caps);
-}
 
 rcc = g_initable_new(TYPE_CURSOR_CHANNEL_CLIENT,
  NULL, NULL,
@@ -115,16 +103,10 @@ CursorChannelClient* 
cursor_channel_client_new(CursorChannel *cursor, RedClient
  "client", client,
  "stream", stream,
  "monitor-latency", FALSE,
- "common-caps", common_caps_array,
- "caps", caps_array,
+ "caps", caps,
  NULL);
 
common_graphics_channel_set_during_target_migrate(COMMON_GRAPHICS_CHANNEL(cursor),
 mig_target);
 
-if (caps_array)
-g_array_unref(caps_array);
-if (common_caps_array)
-g_array_unref(common_caps_array);
-
 return rcc;
 }
 
diff --git a/server/cursor-channel-client.h b/server/cursor-channel-client.h
index d1dd31d..e2aa3a8 100644
--- a/server/cursor-channel-client.h
+++ b/server/cursor-channel-client.h
@@ -63,9 +63,7 @@ CursorChannelClient* cursor_channel_client_new(CursorChannel 
*cursor,
RedClient *client,
RedsStream *stream,
int mig_target,
-   uint32_t *common_caps,
-   int num_common_caps,
-   uint32_t *caps, int num_caps);
+   RedChannelCapabilities *caps);
 
 void cursor_channel_client_reset_cursor_cache(RedChannelClient *rcc);
 void cursor_channel_client_on_disconnect(RedChannelClient *rcc);
diff --git a/server/cursor-channel.c b/server/cursor-channel.c
index fe56098..9d21962 100644
--- a/server/cursor-channel.c
+++ b/server/cursor-channel.c
@@ -406,8 +406,7 @@ void cursor_channel_set_mouse_mode(CursorChannel *cursor, 
uint32_t mode)
 
 void cursor_channel_connect(CursorChannel *cursor, RedClient *client, 
RedsStream *stream,

[Spice-devel] [PATCH spice-server v4 2/3] red-channel: Separate RedChannelCapabilities

[Frediano Ziglio]

Add function to initialize and destroy this type.
Add GType type for boxing it.
These changes a in preparation for next patch.

Signed-off-by: Frediano Ziglio 
---
 server/Makefile.am|  2 ++
 server/red-channel-capabilities.c | 68 +++
 server/red-channel-capabilities.h | 51 +
 server/red-channel.h  |  8 +
 4 files changed, 122 insertions(+), 7 deletions(-)
 create mode 100644 server/red-channel-capabilities.c
 create mode 100644 server/red-channel-capabilities.h

diff --git a/server/Makefile.am b/server/Makefile.am
index a043660..49c0822 100644
--- a/server/Makefile.am
+++ b/server/Makefile.am
@@ -101,6 +101,8 @@ libserver_la_SOURCES =  \
red-channel.h   \
red-channel-client.c\
red-channel-client.h\
+   red-channel-capabilities.c  \
+   red-channel-capabilities.h  \
red-client.c\
red-client.h\
red-common.h\
diff --git a/server/red-channel-capabilities.c 
b/server/red-channel-capabilities.c
new file mode 100644
index 000..eacb338
--- /dev/null
+++ b/server/red-channel-capabilities.c
@@ -0,0 +1,68 @@
+/*
+   Copyright (C) 2017 Red Hat, Inc.
+
+   This library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   This library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with this library; if not, see .
+*/
+#ifdef HAVE_CONFIG_H
+#include 
+#endif
+
+#include 
+#include 
+#include 
+
+#include "red-channel-capabilities.h"
+
+GType red_channel_capabilities_type;
+
+void red_channel_capabilities_init(RedChannelCapabilities *dest,
+   const RedChannelCapabilities *caps)
+{
+*dest = *caps;
+if (caps->common_caps) {
+dest->common_caps = spice_memdup(caps->common_caps,
+ caps->num_common_caps * 
sizeof(uint32_t));
+}
+if (caps->num_caps) {
+dest->caps = spice_memdup(caps->caps, caps->num_caps * 
sizeof(uint32_t));
+}
+}
+
+void red_channel_capabilities_reset(RedChannelCapabilities *caps)
+{
+free(caps->common_caps);
+free(caps->caps);
+memset(caps, 0, sizeof(*caps));
+}
+
+static RedChannelCapabilities *red_channel_capabilities_dup(const 
RedChannelCapabilities *caps)
+{
+RedChannelCapabilities *res = spice_new(RedChannelCapabilities, 1);
+red_channel_capabilities_init(res, caps);
+return res;
+}
+
+static void red_channel_capabilities_free(RedChannelCapabilities *caps)
+{
+red_channel_capabilities_reset(caps);
+free(caps);
+}
+
+SPICE_CONSTRUCTOR_FUNC(red_channel_capabilities_construct)
+{
+red_channel_capabilities_type =
+g_boxed_type_register_static("red_channel_capabilities_type",
+ (GBoxedCopyFunc) 
red_channel_capabilities_dup,
+ (GBoxedFreeFunc) 
red_channel_capabilities_free);
+}
diff --git a/server/red-channel-capabilities.h 
b/server/red-channel-capabilities.h
new file mode 100644
index 000..299409d
--- /dev/null
+++ b/server/red-channel-capabilities.h
@@ -0,0 +1,51 @@
+/* -*- Mode: C; c-basic-offset: 4; indent-tabs-mode: nil -*- */
+/*
+   Copyright (C) 2009-2017 Red Hat, Inc.
+
+   This library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   This library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with this library; if not, see .
+*/
+
+#ifndef RED_CHANNEL_CAPABILITIES_H_
+#define RED_CHANNEL_CAPABILITIES_H_
+
+#include 
+#include 
+
+G_BEGIN_DECLS
+
+/* Holds channel capabilities.
+ * Channel capabilities are composed by a common part
+ * and a specific one. */
+typedef struct RedChannelCapabilities {
+int num_common_caps;
+uint32_t *common_caps;
+int num_caps;
+uint32_t *caps;
+} RedChannelCapabilit

[Spice-devel] [PATCH spice-server v4 0/3] Change the way we pass capabilities

[Frediano Ziglio]

This patchset attempt to pass capabilities using a single
RedChannelCapabilities (already existing) structure.

Changes since v3:
- revert some indentation;
- define and use a TYPE_RED_CHANNEL_CAPABILITIES;
- minor style changes.

Changes since v2:
- merge GArray and RedChannelCapabilites usage;
- split removing reading capability properties;
- move object to separate files.

Changes since v1:
- use RedChannelCapabilities instead of 2 GArrays.

Frediano Ziglio (3):
  red-channel-client: Make capabilities property write only
  red-channel: Separate RedChannelCapabilities
  red-channel: Use RedChannelCapabilities directly to pass capabilities

 server/Makefile.am|  2 +
 server/cursor-channel-client.c| 22 +--
 server/cursor-channel-client.h|  4 +-
 server/cursor-channel.c   |  6 +--
 server/cursor-channel.h   |  3 +-
 server/dcc.c  | 22 +--
 server/dcc.h  |  5 +--
 server/inputs-channel-client.c| 23 +--
 server/inputs-channel-client.h|  5 +--
 server/inputs-channel.c   |  7 +---
 server/main-channel-client.c  | 22 +--
 server/main-channel-client.h  |  3 +-
 server/main-channel.c |  7 +---
 server/main-channel.h |  4 +-
 server/red-channel-capabilities.c | 68 +
 server/red-channel-capabilities.h | 51 +
 server/red-channel-client.c   | 80 ---
 server/red-channel-client.h   |  3 +-
 server/red-channel.c  | 19 +++---
 server/red-channel.h  | 15 ++--
 server/red-qxl.c  | 24 +++-
 server/red-qxl.h  | 10 +
 server/red-worker.c   | 11 ++
 server/reds.c | 41 ++--
 server/smartcard-channel-client.c | 22 +--
 server/smartcard-channel-client.h |  3 +-
 server/smartcard.c|  6 +--
 server/sound.c| 37 --
 server/spicevmc.c | 11 +++---
 29 files changed, 217 insertions(+), 319 deletions(-)
 create mode 100644 server/red-channel-capabilities.c
 create mode 100644 server/red-channel-capabilities.h

-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server v4 1/3] red-channel-client: Make capabilities property write only

[Frediano Ziglio]

These properties are not read and code is broken (the content of
the array would be uninitialized).

Signed-off-by: Frediano Ziglio 
Acked-by: Christophe Fergeau 
---
 server/red-channel-client.c | 20 ++--
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/server/red-channel-client.c b/server/red-channel-client.c
index cd4b64e..b6d67e7 100644
--- a/server/red-channel-client.c
+++ b/server/red-channel-client.c
@@ -286,22 +286,6 @@ red_channel_client_get_property(GObject *object,
 case PROP_MONITOR_LATENCY:
 g_value_set_boolean(value, self->priv->monitor_latency);
 break;
-case PROP_COMMON_CAPS:
-{
-GArray *arr = g_array_sized_new(FALSE, FALSE,
-
sizeof(*self->priv->remote_caps.common_caps),
-
self->priv->remote_caps.num_common_caps);
-g_value_take_boxed(value, arr);
-}
-break;
-case PROP_CAPS:
-{
-GArray *arr = g_array_sized_new(FALSE, FALSE,
-
sizeof(*self->priv->remote_caps.caps),
-
self->priv->remote_caps.num_caps);
-g_value_take_boxed(value, arr);
-}
-break;
 default:
 G_OBJECT_WARN_INVALID_PROPERTY_ID(object, property_id, pspec);
 }
@@ -454,7 +438,7 @@ static void 
red_channel_client_class_init(RedChannelClientClass *klass)
   "Common Capabilities",
   G_TYPE_ARRAY,
   G_PARAM_STATIC_STRINGS
-  | G_PARAM_READWRITE
+  | G_PARAM_WRITABLE
   | G_PARAM_CONSTRUCT_ONLY);
 g_object_class_install_property(object_class, PROP_COMMON_CAPS, spec);
 
@@ -462,7 +446,7 @@ static void 
red_channel_client_class_init(RedChannelClientClass *klass)
   "Capabilities",
   G_TYPE_ARRAY,
   G_PARAM_STATIC_STRINGS
-  | G_PARAM_READWRITE
+  | G_PARAM_WRITABLE
   | G_PARAM_CONSTRUCT_ONLY);
 g_object_class_install_property(object_class, PROP_CAPS, spec);
 }
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v3 4/5] red-channel-capabilities: Enhance

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 07:08:08AM -0500, Frediano Ziglio wrote:
> Does it actually make sense the if?
> Maybe free is enough, if the pointer is valid is supposed to
> came from a malloc.

Ah right, wanted to tell to drop the if(), but then forgot :)

Christophe


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v3 4/5] red-channel-capabilities: Enhance

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 07:03:55AM -0500, Frediano Ziglio wrote:
> I used TYPE_RED_CHANNEL_CAPABILITIES define, seems more consistent with
> other code and keep the "RedChannel" together.

I disagree, RedChannel is for example RED_TYPE_CHANNEL, not
TYPE_RED_CHANNEL.
The way I see it is that 'red' (and sometimes 'reds' or 'spice') is our
namespace, just like 'g' is glib's namespace. So just like we have
G_TYPE_OBJECT, we should use RED_TYPE_XXX

We happen to have various objects with no namespace (sndchannel, ...),
in this case the types are indeed TYPE_XXX. I would not encourage
types without the red namespace, but TYPE_RED is definitely not correct.

Christophe


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v3 5/5] red-channel: Use RedChannelCapabilities directly to pass capabilities

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 09:16:11AM +, Frediano Ziglio wrote:
> For each channel there are two set of capabilities, one
> for the common ones and one for the specific ones.
> A single set were almost always passed using 2 arguments,
> a number of elements and an array but then before using
> these were converted to a GArray.
> Use a single structure (already available) to pass all
> channel capabilites using a single argument.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/cursor-channel-client.c| 22 ++
>  server/cursor-channel-client.h|  4 +--
>  server/cursor-channel.c   |  6 ++--
>  server/cursor-channel.h   |  9 +++---
>  server/dcc.c  | 22 ++
>  server/dcc.h  | 16 --
>  server/inputs-channel-client.c| 23 ++-
>  server/inputs-channel-client.h|  5 +---
>  server/inputs-channel.c   |  7 ++---
>  server/main-channel-client.c  | 22 ++
>  server/main-channel-client.h  |  3 +-
>  server/main-channel.c |  7 ++---
>  server/main-channel.h |  4 +--
>  server/red-channel-client.c   | 62 
> +--
>  server/red-channel-client.h   |  3 +-
>  server/red-channel.c  | 19 
>  server/red-channel.h  |  7 ++---
>  server/red-qxl.c  | 24 ---
>  server/red-qxl.h  | 10 ++-
>  server/red-worker.c   | 11 +++
>  server/reds.c | 37 +++
>  server/smartcard-channel-client.c | 22 ++
>  server/smartcard-channel-client.h |  3 +-
>  server/smartcard.c|  6 ++--
>  server/sound.c| 37 +--
>  server/spicevmc.c | 11 ---
>  26 files changed, 97 insertions(+), 305 deletions(-)

Nice removal :)

> 
> diff --git a/server/cursor-channel-client.c b/server/cursor-channel-client.c
> index 56efd1e..1a05f73 100644
> --- a/server/cursor-channel-client.c
> +++ b/server/cursor-channel-client.c
> @@ -93,21 +93,9 @@ void cursor_channel_client_migrate(RedChannelClient *rcc)
>  
>  CursorChannelClient* cursor_channel_client_new(CursorChannel *cursor, 
> RedClient *client, RedsStream *stream,
> int mig_target,
> -   uint32_t *common_caps, int 
> num_common_caps,
> -   uint32_t *caps, int num_caps)
> +   RedChannelCapabilities *caps)
>  {
>  CursorChannelClient *rcc;
> -GArray *common_caps_array = NULL, *caps_array = NULL;
> -
> -if (common_caps) {
> -common_caps_array = g_array_sized_new(FALSE, FALSE, sizeof 
> (*common_caps),
> -  num_common_caps);
> -g_array_append_vals(common_caps_array, common_caps, num_common_caps);
> -}
> -if (caps) {
> -caps_array = g_array_sized_new(FALSE, FALSE, sizeof (*caps), 
> num_caps);
> -g_array_append_vals(caps_array, caps, num_caps);
> -}
>  
>  rcc = g_initable_new(TYPE_CURSOR_CHANNEL_CLIENT,
>   NULL, NULL,
> @@ -115,16 +103,10 @@ CursorChannelClient* 
> cursor_channel_client_new(CursorChannel *cursor, RedClient
>   "client", client,
>   "stream", stream,
>   "monitor-latency", FALSE,
> - "common-caps", common_caps_array,
> - "caps", caps_array,
> + "caps", caps,
>   NULL);
>  
> common_graphics_channel_set_during_target_migrate(COMMON_GRAPHICS_CHANNEL(cursor),
>  mig_target);
>  
> -if (caps_array)
> -g_array_unref(caps_array);
> -if (common_caps_array)
> -g_array_unref(common_caps_array);
> -
>  return rcc;
>  }
>  
> diff --git a/server/cursor-channel-client.h b/server/cursor-channel-client.h
> index d1dd31d..e2aa3a8 100644
> --- a/server/cursor-channel-client.h
> +++ b/server/cursor-channel-client.h
> @@ -63,9 +63,7 @@ CursorChannelClient* 
> cursor_channel_client_new(CursorChannel *cursor,
> RedClient *client,
> RedsStream *stream,
> int mig_target,
> -   uint32_t *common_caps,
> -   int num_common_caps,
> -   uint32_t *caps, int num_caps);
> +   RedChannelCapabilities *caps);
>  
>  void cursor_channel_client_reset_cursor_cache(RedChannelClient *rcc);
>  void cursor_channel_client_on_disconnect(RedChannelClient *rcc);
> diff --git a/server/cursor-channel.c b/server

Re: [Spice-devel] [PATCH spice-server v3 4/5] red-channel-capabilities: Enhance

[Frediano Ziglio]

> 
> On Thu, Mar 02, 2017 at 09:16:10AM +, Frediano Ziglio wrote:
> > Add function to initialize and destroy this type.
> > Add GObject type for boxing it.
> 
> Nit: I would not call 'GObject type' a GType/GBoxed GObject.
> 
> 
> > These changes a in preparation for next patch.
> > 
> > Signed-off-by: Frediano Ziglio 
> > ---
> >  server/red-channel-capabilities.c | 55
> >  +++
> >  server/red-channel-capabilities.h | 16 +++-
> >  2 files changed, 70 insertions(+), 1 deletion(-)
> > 
> > diff --git a/server/red-channel-capabilities.c
> > b/server/red-channel-capabilities.c
> > index 39bde66..dc28298 100644
> > --- a/server/red-channel-capabilities.c
> > +++ b/server/red-channel-capabilities.c
> > @@ -18,5 +18,60 @@
> >  #include 
> >  #endif
> >  
> > +#include 
> > +#include 
> > +#include 
> > +
> >  #include "red-channel-capabilities.h"
> >  
> > +GType red_channel_capabilities_type;
> > +
> > +void red_channel_capabilities_init(RedChannelCapabilities *dest,
> > +   const RedChannelCapabilities *caps)
> > +{
> > +*dest = *caps;
> > +if (caps->common_caps) {
> > +dest->common_caps = spice_memdup(caps->common_caps,
> > + caps->num_common_caps *
> > sizeof(uint32_t));
> > +}
> > +if (caps->num_caps) {
> > +dest->caps = spice_memdup(caps->caps, caps->num_caps *
> > sizeof(uint32_t));
> > +}
> > +}
> > +
> > +void red_channel_capabilities_reset(RedChannelCapabilities *caps)
> > +{
> > +if (caps->num_common_caps) {
> > +free(caps->common_caps);
> > +}
> > +
> > +if (caps->num_caps) {
> > +free(caps->caps);
> > +}

Does it actually make sense the if?
Maybe free is enough, if the pointer is valid is supposed to
came from a malloc.

> > +memset(caps, 0, sizeof(*caps));
> > +}
> > +
> > +static RedChannelCapabilities *red_channel_capabilities_dup(const
> > RedChannelCapabilities *caps)
> > +{
> > +if (!caps) {
> > +return NULL;
> > +}
> 
> It's apparently invalid to return NULL from a GBoxedCopyFunc. Dunno if
> the 'caps' argument can validly be NULL or not, probably not?
> 
> > +
> > +RedChannelCapabilities *res = spice_new(RedChannelCapabilities, 1);
> > +red_channel_capabilities_init(res, caps);
> > +return res;
> > +}
> > +
> > +static void red_channel_capabilities_free(RedChannelCapabilities *caps)
> > +{
> > +red_channel_capabilities_reset(caps);
> > +free(caps);
> > +}
> > +
> > +SPICE_CONSTRUCTOR_FUNC(red_channel_capabilities_construct)
> > +{
> > +red_channel_capabilities_type =
> > +g_boxed_type_register_static("red_channel_capabilities_type",
> > + (GBoxedCopyFunc)
> > red_channel_capabilities_dup,
> > + (GBoxedFreeFunc)
> > red_channel_capabilities_free);
> > +}
> > diff --git a/server/red-channel-capabilities.h
> > b/server/red-channel-capabilities.h
> > index 8729134..1f52cd4 100644
> > --- a/server/red-channel-capabilities.h
> > +++ b/server/red-channel-capabilities.h
> > @@ -20,10 +20,13 @@
> >  #define RED_CHANNEL_CAPABILITIES_H_
> >  
> >  #include 
> > -#include 
> > +#include 
> >  
> >  G_BEGIN_DECLS
> >  
> > +/* Holds channel capabilities.
> > + * Channel capabilities are composed by a common part
> > + * and a specific one. */
> >  typedef struct RedChannelCapabilities {
> >  int num_common_caps;
> >  uint32_t *common_caps;
> > @@ -31,6 +34,17 @@ typedef struct RedChannelCapabilities {
> >  uint32_t *caps;
> >  } RedChannelCapabilities;
> >  
> > +/* Initialize the structure based on a previous one. */
> > +void red_channel_capabilities_init(RedChannelCapabilities *dest,
> > +   const RedChannelCapabilities *caps);
> > +
> > +/* Reset capabilities.
> > + * All resources are freed by this function. */
> > +void red_channel_capabilities_reset(RedChannelCapabilities *caps);
> > +
> > +/* GObject type that can be used to box RedChannelCapabilities */
> > +extern GType red_channel_capabilities_type;
> 
> Usually a _get_type() method is exported, together with a #define.
> You favoured using a static constructor, but I'd still add a
> #define RED_TYPE_CHANNEL_CAPABILITIES red_channel_capabilities_type
> for consistency with the other GType names.
> 
> 
> Looks good to me.
> 
> Christophe
> 
Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v3 4/5] red-channel-capabilities: Enhance

[Frediano Ziglio]

> 
> On Thu, Mar 02, 2017 at 09:16:10AM +, Frediano Ziglio wrote:
> > Add function to initialize and destroy this type.
> > Add GObject type for boxing it.
> 
> Nit: I would not call 'GObject type' a GType/GBoxed GObject.
> 
> 
> > These changes a in preparation for next patch.
> > 
> > Signed-off-by: Frediano Ziglio 
> > ---
> >  server/red-channel-capabilities.c | 55
> >  +++
> >  server/red-channel-capabilities.h | 16 +++-
> >  2 files changed, 70 insertions(+), 1 deletion(-)
> > 
> > diff --git a/server/red-channel-capabilities.c
> > b/server/red-channel-capabilities.c
> > index 39bde66..dc28298 100644
> > --- a/server/red-channel-capabilities.c
> > +++ b/server/red-channel-capabilities.c
> > @@ -18,5 +18,60 @@
> >  #include 
> >  #endif
> >  
> > +#include 
> > +#include 
> > +#include 
> > +
> >  #include "red-channel-capabilities.h"
> >  
> > +GType red_channel_capabilities_type;
> > +
> > +void red_channel_capabilities_init(RedChannelCapabilities *dest,
> > +   const RedChannelCapabilities *caps)
> > +{
> > +*dest = *caps;
> > +if (caps->common_caps) {
> > +dest->common_caps = spice_memdup(caps->common_caps,
> > + caps->num_common_caps *
> > sizeof(uint32_t));
> > +}
> > +if (caps->num_caps) {
> > +dest->caps = spice_memdup(caps->caps, caps->num_caps *
> > sizeof(uint32_t));
> > +}
> > +}
> > +
> > +void red_channel_capabilities_reset(RedChannelCapabilities *caps)
> > +{
> > +if (caps->num_common_caps) {
> > +free(caps->common_caps);
> > +}
> > +
> > +if (caps->num_caps) {
> > +free(caps->caps);
> > +}
> > +memset(caps, 0, sizeof(*caps));
> > +}
> > +
> > +static RedChannelCapabilities *red_channel_capabilities_dup(const
> > RedChannelCapabilities *caps)
> > +{
> > +if (!caps) {
> > +return NULL;
> > +}
> 
> It's apparently invalid to return NULL from a GBoxedCopyFunc. Dunno if
> the 'caps' argument can validly be NULL or not, probably not?
> 

Yes, removed.

> > +
> > +RedChannelCapabilities *res = spice_new(RedChannelCapabilities, 1);
> > +red_channel_capabilities_init(res, caps);
> > +return res;
> > +}
> > +
> > +static void red_channel_capabilities_free(RedChannelCapabilities *caps)
> > +{
> > +red_channel_capabilities_reset(caps);
> > +free(caps);
> > +}
> > +
> > +SPICE_CONSTRUCTOR_FUNC(red_channel_capabilities_construct)
> > +{
> > +red_channel_capabilities_type =
> > +g_boxed_type_register_static("red_channel_capabilities_type",
> > + (GBoxedCopyFunc)
> > red_channel_capabilities_dup,
> > + (GBoxedFreeFunc)
> > red_channel_capabilities_free);
> > +}
> > diff --git a/server/red-channel-capabilities.h
> > b/server/red-channel-capabilities.h
> > index 8729134..1f52cd4 100644
> > --- a/server/red-channel-capabilities.h
> > +++ b/server/red-channel-capabilities.h
> > @@ -20,10 +20,13 @@
> >  #define RED_CHANNEL_CAPABILITIES_H_
> >  
> >  #include 
> > -#include 
> > +#include 
> >  
> >  G_BEGIN_DECLS
> >  
> > +/* Holds channel capabilities.
> > + * Channel capabilities are composed by a common part
> > + * and a specific one. */
> >  typedef struct RedChannelCapabilities {
> >  int num_common_caps;
> >  uint32_t *common_caps;
> > @@ -31,6 +34,17 @@ typedef struct RedChannelCapabilities {
> >  uint32_t *caps;
> >  } RedChannelCapabilities;
> >  
> > +/* Initialize the structure based on a previous one. */
> > +void red_channel_capabilities_init(RedChannelCapabilities *dest,
> > +   const RedChannelCapabilities *caps);
> > +
> > +/* Reset capabilities.
> > + * All resources are freed by this function. */
> > +void red_channel_capabilities_reset(RedChannelCapabilities *caps);
> > +
> > +/* GObject type that can be used to box RedChannelCapabilities */
> > +extern GType red_channel_capabilities_type;
> 
> Usually a _get_type() method is exported, together with a #define.
> You favoured using a static constructor, but I'd still add a
> #define RED_TYPE_CHANNEL_CAPABILITIES red_channel_capabilities_type
> for consistency with the other GType names.
> 
> 
> Looks good to me.
> 
> Christophe
> 

I used TYPE_RED_CHANNEL_CAPABILITIES define, seems more consistent with
other code and keep the "RedChannel" together.

Frediano
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v3 4/5] red-channel-capabilities: Enhance

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 09:16:10AM +, Frediano Ziglio wrote:
> Add function to initialize and destroy this type.
> Add GObject type for boxing it.

Nit: I would not call 'GObject type' a GType/GBoxed GObject.


> These changes a in preparation for next patch.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/red-channel-capabilities.c | 55 
> +++
>  server/red-channel-capabilities.h | 16 +++-
>  2 files changed, 70 insertions(+), 1 deletion(-)
> 
> diff --git a/server/red-channel-capabilities.c 
> b/server/red-channel-capabilities.c
> index 39bde66..dc28298 100644
> --- a/server/red-channel-capabilities.c
> +++ b/server/red-channel-capabilities.c
> @@ -18,5 +18,60 @@
>  #include 
>  #endif
>  
> +#include 
> +#include 
> +#include 
> +
>  #include "red-channel-capabilities.h"
>  
> +GType red_channel_capabilities_type;
> +
> +void red_channel_capabilities_init(RedChannelCapabilities *dest,
> +   const RedChannelCapabilities *caps)
> +{
> +*dest = *caps;
> +if (caps->common_caps) {
> +dest->common_caps = spice_memdup(caps->common_caps,
> + caps->num_common_caps * 
> sizeof(uint32_t));
> +}
> +if (caps->num_caps) {
> +dest->caps = spice_memdup(caps->caps, caps->num_caps * 
> sizeof(uint32_t));
> +}
> +}
> +
> +void red_channel_capabilities_reset(RedChannelCapabilities *caps)
> +{
> +if (caps->num_common_caps) {
> +free(caps->common_caps);
> +}
> +
> +if (caps->num_caps) {
> +free(caps->caps);
> +}
> +memset(caps, 0, sizeof(*caps));
> +}
> +
> +static RedChannelCapabilities *red_channel_capabilities_dup(const 
> RedChannelCapabilities *caps)
> +{
> +if (!caps) {
> +return NULL;
> +}

It's apparently invalid to return NULL from a GBoxedCopyFunc. Dunno if
the 'caps' argument can validly be NULL or not, probably not?

> +
> +RedChannelCapabilities *res = spice_new(RedChannelCapabilities, 1);
> +red_channel_capabilities_init(res, caps);
> +return res;
> +}
> +
> +static void red_channel_capabilities_free(RedChannelCapabilities *caps)
> +{
> +red_channel_capabilities_reset(caps);
> +free(caps);
> +}
> +
> +SPICE_CONSTRUCTOR_FUNC(red_channel_capabilities_construct)
> +{
> +red_channel_capabilities_type =
> +g_boxed_type_register_static("red_channel_capabilities_type",
> + (GBoxedCopyFunc) 
> red_channel_capabilities_dup,
> + (GBoxedFreeFunc) 
> red_channel_capabilities_free);
> +}
> diff --git a/server/red-channel-capabilities.h 
> b/server/red-channel-capabilities.h
> index 8729134..1f52cd4 100644
> --- a/server/red-channel-capabilities.h
> +++ b/server/red-channel-capabilities.h
> @@ -20,10 +20,13 @@
>  #define RED_CHANNEL_CAPABILITIES_H_
>  
>  #include 
> -#include 
> +#include 
>  
>  G_BEGIN_DECLS
>  
> +/* Holds channel capabilities.
> + * Channel capabilities are composed by a common part
> + * and a specific one. */
>  typedef struct RedChannelCapabilities {
>  int num_common_caps;
>  uint32_t *common_caps;
> @@ -31,6 +34,17 @@ typedef struct RedChannelCapabilities {
>  uint32_t *caps;
>  } RedChannelCapabilities;
>  
> +/* Initialize the structure based on a previous one. */
> +void red_channel_capabilities_init(RedChannelCapabilities *dest,
> +   const RedChannelCapabilities *caps);
> +
> +/* Reset capabilities.
> + * All resources are freed by this function. */
> +void red_channel_capabilities_reset(RedChannelCapabilities *caps);
> +
> +/* GObject type that can be used to box RedChannelCapabilities */
> +extern GType red_channel_capabilities_type;

Usually a _get_type() method is exported, together with a #define.
You favoured using a static constructor, but I'd still add a
#define RED_TYPE_CHANNEL_CAPABILITIES red_channel_capabilities_type
for consistency with the other GType names.


Looks good to me.

Christophe

> +
>  G_END_DECLS
>  
>  #endif
> -- 
> 2.9.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v3 3/5] red-channel: Separate RedChannelCapabilities

[Christophe Fergeau]

I'd merge that with the next commit.

On Thu, Mar 02, 2017 at 09:16:09AM +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio 
> ---
>  server/Makefile.am|  2 ++
>  server/red-channel-capabilities.c | 22 ++
>  server/red-channel-capabilities.h | 36 
>  server/red-channel.h  |  8 +---
>  4 files changed, 61 insertions(+), 7 deletions(-)
>  create mode 100644 server/red-channel-capabilities.c
>  create mode 100644 server/red-channel-capabilities.h
> 
> diff --git a/server/Makefile.am b/server/Makefile.am
> index a043660..49c0822 100644
> --- a/server/Makefile.am
> +++ b/server/Makefile.am
> @@ -101,6 +101,8 @@ libserver_la_SOURCES =\
>   red-channel.h   \
>   red-channel-client.c\
>   red-channel-client.h\
> + red-channel-capabilities.c  \
> + red-channel-capabilities.h  \
>   red-client.c\
>   red-client.h\
>   red-common.h\
> diff --git a/server/red-channel-capabilities.c 
> b/server/red-channel-capabilities.c
> new file mode 100644
> index 000..39bde66
> --- /dev/null
> +++ b/server/red-channel-capabilities.c
> @@ -0,0 +1,22 @@
> +/*
> +   Copyright (C) 2017 Red Hat, Inc.
> +
> +   This library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   This library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with this library; if not, see 
> .
> +*/
> +#ifdef HAVE_CONFIG_H
> +#include 
> +#endif
> +
> +#include "red-channel-capabilities.h"
> +
> diff --git a/server/red-channel-capabilities.h 
> b/server/red-channel-capabilities.h
> new file mode 100644
> index 000..8729134
> --- /dev/null
> +++ b/server/red-channel-capabilities.h
> @@ -0,0 +1,36 @@
> +/* -*- Mode: C; c-basic-offset: 4; indent-tabs-mode: nil -*- */
> +/*
> +   Copyright (C) 2009-2017 Red Hat, Inc.
> +
> +   This library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   This library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with this library; if not, see 
> .
> +*/
> +
> +#ifndef RED_CHANNEL_CAPABILITIES_H_
> +#define RED_CHANNEL_CAPABILITIES_H_
> +
> +#include 
> +#include 
> +
> +G_BEGIN_DECLS
> +
> +typedef struct RedChannelCapabilities {
> +int num_common_caps;
> +uint32_t *common_caps;
> +int num_caps;
> +uint32_t *caps;
> +} RedChannelCapabilities;
> +
> +G_END_DECLS
> +
> +#endif
> diff --git a/server/red-channel.h b/server/red-channel.h
> index 79aee01..6cee35f 100644
> --- a/server/red-channel.h
> +++ b/server/red-channel.h
> @@ -34,6 +34,7 @@
>  #include "reds-stream.h"
>  #include "stat.h"
>  #include "red-pipe-item.h"
> +#include "red-channel-capabilities.h"
>  
>  G_BEGIN_DECLS
>  
> @@ -135,13 +136,6 @@ struct RedChannelClass
>  
>  /* Red Channel interface */
>  
> -typedef struct RedChannelCapabilities {
> -int num_common_caps;
> -uint32_t *common_caps;
> -int num_caps;
> -uint32_t *caps;
> -} RedChannelCapabilities;
> -
>  GType red_channel_get_type(void) G_GNUC_CONST;
>  
>  void red_channel_add_client(RedChannel *channel, RedChannelClient *rcc);
> -- 
> 2.9.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v3 2/5] red-channel-client: Make capabilities property write only

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 09:16:08AM +, Frediano Ziglio wrote:
> These properties are not read and code is broken (you would get
> uninitialized values).

Acked-by: Christophe Fergeau 

(maybe the more specific "the content of the array would be uninitialized"
rather than "you would get uninitialized values").



> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/red-channel-client.c | 20 ++--
>  1 file changed, 2 insertions(+), 18 deletions(-)
> 
> diff --git a/server/red-channel-client.c b/server/red-channel-client.c
> index b583da2..2d2e3fd 100644
> --- a/server/red-channel-client.c
> +++ b/server/red-channel-client.c
> @@ -286,22 +286,6 @@ red_channel_client_get_property(GObject *object,
>  case PROP_MONITOR_LATENCY:
>  g_value_set_boolean(value, self->priv->monitor_latency);
>  break;
> -case PROP_COMMON_CAPS:
> -{
> -GArray *arr = g_array_sized_new(FALSE, FALSE,
> -
> sizeof(*self->priv->remote_caps.common_caps),
> -
> self->priv->remote_caps.num_common_caps);
> -g_value_take_boxed(value, arr);
> -}
> -break;
> -case PROP_CAPS:
> -{
> -GArray *arr = g_array_sized_new(FALSE, FALSE,
> -
> sizeof(*self->priv->remote_caps.caps),
> -
> self->priv->remote_caps.num_caps);
> -g_value_take_boxed(value, arr);
> -}
> -break;
>  default:
>  G_OBJECT_WARN_INVALID_PROPERTY_ID(object, property_id, pspec);
>  }
> @@ -454,7 +438,7 @@ static void 
> red_channel_client_class_init(RedChannelClientClass *klass)
>"Common Capabilities",
>G_TYPE_ARRAY,
>G_PARAM_STATIC_STRINGS
> -  | G_PARAM_READWRITE
> +  | G_PARAM_WRITABLE
>| G_PARAM_CONSTRUCT_ONLY);
>  g_object_class_install_property(object_class, PROP_COMMON_CAPS, spec);
>  
> @@ -462,7 +446,7 @@ static void 
> red_channel_client_class_init(RedChannelClientClass *klass)
>"Capabilities",
>G_TYPE_ARRAY,
>G_PARAM_STATIC_STRINGS
> -  | G_PARAM_READWRITE
> +  | G_PARAM_WRITABLE
>| G_PARAM_CONSTRUCT_ONLY);
>  g_object_class_install_property(object_class, PROP_CAPS, spec);
>  }
> -- 
> 2.9.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server v3 1/5] red-channel: Remove unused type definition

[Christophe Fergeau]

Acked-by: Christophe Fergeau 

On Thu, Mar 02, 2017 at 09:16:07AM +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio 
> ---
> I don't consider this patch really specific to this set

Yup, definitely not.

> ---
>  server/red-channel.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/server/red-channel.c b/server/red-channel.c
> index 67a570d..8fe0d33 100644
> --- a/server/red-channel.c
> +++ b/server/red-channel.c
> @@ -594,7 +594,6 @@ int red_channel_no_item_being_sent(RedChannel *channel)
>   */
>  
>  typedef void (*rcc_item_t)(RedChannelClient *rcc, RedPipeItem *item);
> -typedef int (*rcc_item_cond_t)(RedChannelClient *rcc, RedPipeItem *item);
>  
>  /**
>   * red_channel_pipes_create_batch:
> -- 
> 2.9.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH v2 0/2] RHEL7 improvements

[Frediano Ziglio]

These 2 patches attempt to join images split by RHEL7 graphic
stack (Mesa) decreasing commands handled by spice-server.

You can see the difference between the 2 video:
- https://www.youtube.com/watch?v=OarV6zUmUdg (before)
- https://www.youtube.com/watch?v=5fTdCCbFeCg (after)
These video are realized with some additional changes:
- the statistics from the terminal have some additional
  "out_messages" counters. These counters show the messages
  sent to the client(s). These changes are part of my "stat"
  branch (partially sent couple of days ago);
- the replay utility, as you can see, was changed to replay
  using the real time to allow the video code (which is dependent
  on timing) to work correctly. The patch is currently not in
  a good shape (enough to be sent);
- the client utility was changed to remove the delay due to
  the lip sync. The glitches (present mostly before these patches)
  are much reduced.

Note the number of commands sent to the client reduced from 6097
to 2016 (current year, just a coincidence).
The network traffic reduced from 72M to 56M. This is due to the fact
that having a single stream (as you can see VP8 codec was used) the
compression on the stream is better.

These patches fix:
- https://bugzilla.redhat.com/show_bug.cgi?id=1158029;
- (probably) https://bugzilla.redhat.com/show_bug.cgi?id=1294564.

Changes since RFC:
- moved code to DisplayChannel;
- define a constant for timeout.

Future possible optimization: not waiting to join if the joined
command end at the screen bottom or if the last command contain
a small image (Mesa split at about 64K pixel, 256Kb).

In some experiments with the modified replay utility I got
some additional artifacts respect to the RFC version. This is mainly
due to the way RedWorker handle commands from graphic driver and the
way the timeout was handled. In the previous version before checking
for joining timeout the graphic command queue were always checked
while with this last series is possible that the timeout trigger
before checking for new command. This however seems to happen mainly
to me as the replay utility introduce some delay.

Frediano Ziglio (2):
  display-channel: Join drawables to improve rhel7 behaviour
  display-channel: Handle timeout for joining drawables

 server/display-channel-private.h |   6 +-
 server/display-channel.c | 191 +++-
 server/red-parse-qxl.h   |   1 +-
 server/red-worker.c  |  14 +-
 4 files changed, 205 insertions(+), 7 deletions(-)

base-commit: cdd1e69b2881eec45327e27b297b0cbab44b033e
-- 
git-series 0.9.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH v2 2/2] display-channel: Handle timeout for joining drawables

[Frediano Ziglio]

The previous patch join correctly the commands however if there
are no more commands the command joined is delayed till new
commands arrive. This patch introduce a timeout (currently 10 ms)
after the command is executed.

Signed-off-by: Frediano Ziglio 
---
 server/display-channel-private.h |  4 -
 server/display-channel.c | 36 -
 2 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/server/display-channel-private.h b/server/display-channel-private.h
index 62e03b6..e289e45 100644
--- a/server/display-channel-private.h
+++ b/server/display-channel-private.h
@@ -20,6 +20,8 @@
 
 #include "display-channel.h"
 
+#define JOINABLE_TIMEOUT 10 // ms
+
 #define NUM_DRAWABLES 1000
 typedef struct _Drawable _Drawable;
 struct _Drawable {
@@ -69,6 +71,8 @@ struct DisplayChannelPrivate
 
 int gl_draw_async_count;
 
+uint32_t joinable_generation;
+SpiceTimer *joinable_timeout;
 RedDrawable *joinable_drawable;
 
 /* TODO: some day unify this, make it more runtime.. */
diff --git a/server/display-channel.c b/server/display-channel.c
index 37d1703..8993b12 100644
--- a/server/display-channel.c
+++ b/server/display-channel.c
@@ -78,6 +78,9 @@ display_channel_finalize(GObject *object)
 {
 DisplayChannel *self = DISPLAY_CHANNEL(object);
 
+SpiceCoreInterfaceInternal* core = 
red_channel_get_core_interface(RED_CHANNEL(self));
+core->timer_remove(core, self->priv->joinable_timeout);
+
 display_channel_destroy_surfaces(self);
 image_cache_reset(&self->priv->image_cache);
 monitors_config_unref(self->priv->monitors_config);
@@ -1330,17 +1333,23 @@ display_channel_process_draw_single(DisplayChannel 
*display, RedDrawable *red_dr
 drawable_unref(drawable);
 }
 
+static void display_joinable_timeout(void *opaque)
+{
+DisplayChannel *display = opaque;
+if (display->priv->joinable_drawable) {
+display_channel_process_draw_single(display, 
display->priv->joinable_drawable,
+
display->priv->joinable_generation);
+red_drawable_unref(display->priv->joinable_drawable);
+display->priv->joinable_drawable = NULL;
+}
+}
+
 void display_channel_process_draw(DisplayChannel *display, RedDrawable 
*red_drawable,
   uint32_t process_commands_generation)
 {
 if (!red_drawable_joinable(red_drawable)) {
 // not joinable, process all
-if (display->priv->joinable_drawable) {
-display_channel_process_draw_single(display, 
display->priv->joinable_drawable,
-process_commands_generation);
-red_drawable_unref(display->priv->joinable_drawable);
-display->priv->joinable_drawable = NULL;
-}
+display_joinable_timeout(display);
 display_channel_process_draw_single(display, red_drawable, 
process_commands_generation);
 return;
 }
@@ -1351,12 +1360,15 @@ void display_channel_process_draw(DisplayChannel 
*display, RedDrawable *red_draw
 red_drawable = red_drawable_join(display->priv->joinable_drawable, 
red_drawable);
 } else {
 // they can't be joined
-display_channel_process_draw_single(display, 
display->priv->joinable_drawable,
-process_commands_generation);
-red_drawable_unref(display->priv->joinable_drawable);
+display_joinable_timeout(display);
 }
+
 // try to join with next one
 red_drawable_ref(red_drawable);
+
+SpiceCoreInterfaceInternal* core = 
red_channel_get_core_interface(RED_CHANNEL(display));
+core->timer_start(core, display->priv->joinable_timeout, JOINABLE_TIMEOUT);
+display->priv->joinable_generation = process_commands_generation;
 display->priv->joinable_drawable = red_drawable;
 }
 
@@ -2227,6 +2239,12 @@ display_channel_constructed(GObject *object)
 self->priv->stream_video = SPICE_STREAM_VIDEO_OFF;
 display_channel_init_streams(self);
 
+SpiceCoreInterfaceInternal* core = red_channel_get_core_interface(channel);
+self->priv->joinable_timeout = core->timer_add(core, 
display_joinable_timeout, self);
+if (!self->priv->joinable_timeout) {
+spice_error("joinable timer create failed");
+}
+
 red_channel_set_cap(channel, SPICE_DISPLAY_CAP_MONITORS_CONFIG);
 red_channel_set_cap(channel, SPICE_DISPLAY_CAP_PREF_COMPRESSION);
 red_channel_set_cap(channel, SPICE_DISPLAY_CAP_STREAM_REPORT);
-- 
git-series 0.9.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH v2 1/2] display-channel: Join drawables to improve rhel7 behaviour

[Frediano Ziglio]

Due to the way RHEL7 works the images came out from guest using multiple
commands. This increase the commands to the client and cause the
video code to create and handle multiple streams creating some
visual glitches.
This patch attempt to detect and join the multiple commands to
avoid these issues.

Signed-off-by: Frediano Ziglio 
---
 server/display-channel-private.h |   2 +-
 server/display-channel.c | 173 +++-
 server/red-parse-qxl.h   |   1 +-
 server/red-worker.c  |  14 +--
 4 files changed, 183 insertions(+), 7 deletions(-)

diff --git a/server/display-channel-private.h b/server/display-channel-private.h
index da807d1..62e03b6 100644
--- a/server/display-channel-private.h
+++ b/server/display-channel-private.h
@@ -69,6 +69,8 @@ struct DisplayChannelPrivate
 
 int gl_draw_async_count;
 
+RedDrawable *joinable_drawable;
+
 /* TODO: some day unify this, make it more runtime.. */
 stat_info_t add_stat;
 stat_info_t exclude_stat;
diff --git a/server/display-channel.c b/server/display-channel.c
index fa2b281..37d1703 100644
--- a/server/display-channel.c
+++ b/server/display-channel.c
@@ -1175,8 +1175,147 @@ static void display_channel_add_drawable(DisplayChannel 
*display, Drawable *draw
 #endif
 }
 
-void display_channel_process_draw(DisplayChannel *display, RedDrawable 
*red_drawable,
-  uint32_t process_commands_generation)
+/* Check that a given drawable it's a simple copy that can be
+ * possibly be joined to next one.
+ * This is used to undo some engine which split images into
+ * chunks causing more commands and creating multiple streams.
+ * One example is RHEL 7.
+ */
+static gboolean red_drawable_joinable(const RedDrawable *drawable)
+{
+/* these 3 initial tests are arranged to minimize checks as
+ * they are in reverse order of occurrences */
+if (drawable->clip.type != SPICE_CLIP_TYPE_NONE) {
+return FALSE;
+}
+if (drawable->type != QXL_DRAW_COPY) {
+return FALSE;
+}
+if (drawable->effect != QXL_EFFECT_OPAQUE) {
+return FALSE;
+}
+if (drawable->self_bitmap) {
+return FALSE;
+}
+if (drawable->surface_deps[0] != -1 ||
+drawable->surface_deps[1] != -1 ||
+drawable->surface_deps[2] != -1) {
+return FALSE;
+}
+
+const SpiceCopy *copy = &drawable->u.copy;
+if (copy->src_bitmap == NULL) {
+return FALSE;
+}
+if (copy->rop_descriptor != SPICE_ROPD_OP_PUT) {
+return FALSE;
+}
+if (copy->mask.bitmap != NULL) {
+return FALSE;
+}
+
+const SpiceImage *image = copy->src_bitmap;
+if (image->descriptor.type != SPICE_IMAGE_TYPE_BITMAP) {
+return FALSE;
+}
+const SpiceBitmap *bitmap = &image->u.bitmap;
+if (bitmap->format != SPICE_BITMAP_FMT_RGBA && bitmap->format != 
SPICE_BITMAP_FMT_32BIT) {
+return FALSE;
+}
+if (bitmap->flags != SPICE_BITMAP_FLAGS_TOP_DOWN) {
+return FALSE;
+}
+if (bitmap->palette != NULL) {
+return FALSE;
+}
+if (bitmap->data == NULL) {
+return FALSE;
+}
+if (bitmap->data->flags & SPICE_CHUNKS_FLAGS_UNSTABLE) {
+return FALSE;
+}
+if (bitmap->x != image->descriptor.width ||
+bitmap->y != image->descriptor.height) {
+return FALSE;
+}
+/* area should specify all image */
+if (copy->src_area.left != 0 || copy->src_area.top != 0 ||
+copy->src_area.right != bitmap->x || copy->src_area.bottom != 
bitmap->y) {
+return FALSE;
+}
+if (drawable->bbox.right - drawable->bbox.left != bitmap->x ||
+drawable->bbox.bottom - drawable->bbox.top != bitmap->y) {
+return FALSE;
+}
+
+return TRUE;
+}
+
+static gboolean red_drawable_can_join(const RedDrawable *first, const 
RedDrawable *second)
+{
+if (!red_drawable_joinable(first) || !red_drawable_joinable(second)) {
+return FALSE;
+}
+if (first->surface_id != second->surface_id) {
+return FALSE;
+}
+if (first->u.copy.src_bitmap->u.bitmap.format != 
second->u.copy.src_bitmap->u.bitmap.format) {
+return FALSE;
+}
+// they must have the same width
+if (first->u.copy.src_bitmap->u.bitmap.x != 
second->u.copy.src_bitmap->u.bitmap.x ||
+first->u.copy.src_bitmap->u.bitmap.stride != 
second->u.copy.src_bitmap->u.bitmap.stride) {
+return FALSE;
+}
+// check that second is exactly under the first
+if (first->bbox.left != second->bbox.left) {
+return FALSE;
+}
+if (first->bbox.bottom != second->bbox.top) {
+return FALSE;
+}
+// check we can join the chunks
+if (first->u.copy.src_bitmap->u.bitmap.data->flags !=
+second->u.copy.src_bitmap->u.bitmap.data->flags) {
+return FALSE;
+}
+return TRUE;
+}
+
+static SpiceChunks *chunks_join(const SpiceChunks *first, const SpiceChunks 
*second)
+{
+// 

Re: [Spice-devel] [PATCH spice-server] tests: Allows to detect loop leaks in test-leaks

[Frediano Ziglio]

> 
> I'd just squash this one in the previous patch (if you think it's
> needed, with a note in the commit log that the added
> basic_event_loop_destroy() addition allows to see that this leak is
> gone). But feel free to keep it separate if you think it's best.
> 
> Acked-by: Christophe Fergeau 
> 
> Christophe
> 

Done.

Thanks,
  Frediano

> On Wed, Mar 01, 2017 at 05:09:55PM +, Frediano Ziglio wrote:
> > Signed-off-by: Frediano Ziglio 
> > ---
> >  server/tests/test-leaks.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/server/tests/test-leaks.c b/server/tests/test-leaks.c
> > index cd96bc8..b8521f4 100644
> > --- a/server/tests/test-leaks.c
> > +++ b/server/tests/test-leaks.c
> > @@ -47,6 +47,7 @@ static void leaks(void)
> >  g_assert_cmpint(result, ==, 0);
> >  
> >  spice_server_destroy(server);
> > +basic_event_loop_destroy();
> >  }
> >  
> >  int main(int argc, char *argv[])
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server] tests: Allows to detect loop leaks in test-leaks

[Christophe Fergeau]

I'd just squash this one in the previous patch (if you think it's
needed, with a note in the commit log that the added
basic_event_loop_destroy() addition allows to see that this leak is
gone). But feel free to keep it separate if you think it's best.

Acked-by: Christophe Fergeau 

Christophe

On Wed, Mar 01, 2017 at 05:09:55PM +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio 
> ---
>  server/tests/test-leaks.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/server/tests/test-leaks.c b/server/tests/test-leaks.c
> index cd96bc8..b8521f4 100644
> --- a/server/tests/test-leaks.c
> +++ b/server/tests/test-leaks.c
> @@ -47,6 +47,7 @@ static void leaks(void)
>  g_assert_cmpint(result, ==, 0);
>  
>  spice_server_destroy(server);
> +basic_event_loop_destroy();
>  }
>  
>  int main(int argc, char *argv[])
> -- 
> 2.9.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server] main-dispatcher: Remove watch leak

[Christophe Fergeau]

Acked-by: Christophe Fergeau 

On Wed, Mar 01, 2017 at 05:09:54PM +, Frediano Ziglio wrote:
> Watch was added but never removed.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/main-dispatcher.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/server/main-dispatcher.c b/server/main-dispatcher.c
> index 09ac1cc..51d6004 100644
> --- a/server/main-dispatcher.c
> +++ b/server/main-dispatcher.c
> @@ -55,6 +55,7 @@ struct MainDispatcherPrivate
>  {
>  SpiceCoreInterfaceInternal *core; /* weak */
>  RedsState *reds; /* weak */
> +SpiceWatch *watch;
>  };
>  
>  
> @@ -105,6 +106,7 @@ main_dispatcher_set_property(GObject  *object,
>  }
>  
>  static void main_dispatcher_constructed(GObject *object);
> +static void main_dispatcher_finalize(GObject *object);
>  
>  static void
>  main_dispatcher_class_init(MainDispatcherClass *klass)
> @@ -114,6 +116,7 @@ main_dispatcher_class_init(MainDispatcherClass *klass)
>  g_type_class_add_private(klass, sizeof(MainDispatcherPrivate));
>  
>  object_class->constructed = main_dispatcher_constructed;
> +object_class->finalize = main_dispatcher_finalize;
>  object_class->get_property = main_dispatcher_get_property;
>  object_class->set_property = main_dispatcher_set_property;
>  
> @@ -304,10 +307,11 @@ void main_dispatcher_constructed(GObject *object)
>  G_OBJECT_CLASS(main_dispatcher_parent_class)->constructed(object);
>  dispatcher_set_opaque(DISPATCHER(self), self);
>  
> -self->priv->core->watch_add(self->priv->core,
> -dispatcher_get_recv_fd(DISPATCHER(self)),
> -SPICE_WATCH_EVENT_READ, 
> dispatcher_handle_read,
> -self);
> +self->priv->watch =
> +self->priv->core->watch_add(self->priv->core,
> +dispatcher_get_recv_fd(DISPATCHER(self)),
> +SPICE_WATCH_EVENT_READ, 
> dispatcher_handle_read,
> +self);
>  dispatcher_register_handler(DISPATCHER(self), 
> MAIN_DISPATCHER_CHANNEL_EVENT,
>  main_dispatcher_handle_channel_event,
>  sizeof(MainDispatcherChannelEventMessage), 0 
> /* no ack */);
> @@ -321,3 +325,11 @@ void main_dispatcher_constructed(GObject *object)
>  main_dispatcher_handle_client_disconnect,
>  
> sizeof(MainDispatcherClientDisconnectMessage), 0 /* no ack */);
>  }
> +
> +static void main_dispatcher_finalize(GObject *object)
> +{
> +MainDispatcher *self = MAIN_DISPATCHER(object);
> +
> +self->priv->core->watch_remove(self->priv->core, self->priv->watch);
> +self->priv->watch = NULL;
> +}
> -- 
> 2.9.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk] spicy: Add dialog for precise resizing

[Victor Toso]

Hi,

On Thu, Mar 02, 2017 at 10:49:24AM +0100, Pavel Grunt wrote:
> It helps when testing whether the guest resizes to requested resolution
>
> Also it gives spicy a basic multimonitor support

1-) IMHO we should enable multi monitor elsewhere
2-) The switch should keep the state of the resizing boolean for given
display
3-) I was not able to disable resizing + resizing it at the same time in
the current display 0 but I can when we are enabling a new
display... bug? :-)

> ---
>  tools/spicy.c | 72 
> +++
>  1 file changed, 72 insertions(+)
> 
> diff --git a/tools/spicy.c b/tools/spicy.c
> index ce6b40b..83ce6d5 100644
> --- a/tools/spicy.c
> +++ b/tools/spicy.c
> @@ -566,6 +566,70 @@ static void keyboard_grab_cb(GtkWidget *widget, gint 
> grabbed, gpointer data)
>  }
>  }
>  
> +static void menu_cb_resize_to(GtkAction *action G_GNUC_UNUSED,
> +  gpointer data)
> +{
> +SpiceWindow *win = data;
> +GtkWidget *dialog, *enable_display;
> +GtkWidget *spin_width, *spin_height, *spin_x, *spin_y, *spin_id;
> +GtkGrid *grid;
> +gint width, height;
> +dialog = gtk_dialog_new_with_buttons("Resize guest to",
> + GTK_WINDOW(win->toplevel),
> + GTK_DIALOG_DESTROY_WITH_PARENT,
> + "_Apply",
> + GTK_RESPONSE_APPLY,
> + "_Cancel",
> + GTK_RESPONSE_CANCEL,
> + NULL);
> +
> +enable_display = gtk_switch_new();
> +gtk_switch_set_state(GTK_SWITCH(enable_display), TRUE);
> +
> +spin_width = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
> +spin_height = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
> +spin_x = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
> +spin_y = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
> +spin_id = gtk_spin_button_new_with_range(0, CHANNELID_MAX * 
> MONITORID_MAX - 1, 1);
> +
> +gtk_widget_get_preferred_width(win->spice, NULL, &width);
> +gtk_widget_get_preferred_height(win->spice, NULL, &height);
> +
> +gtk_spin_button_set_value(GTK_SPIN_BUTTON(spin_width), width);
> +gtk_spin_button_set_value(GTK_SPIN_BUTTON(spin_height), height);
> +gtk_spin_button_set_value(GTK_SPIN_BUTTON(spin_id), win->id + 
> win->monitor_id);
> +
> +grid = GTK_GRID(gtk_grid_new());
> +
> gtk_container_add(GTK_CONTAINER(gtk_dialog_get_content_area(GTK_DIALOG(dialog))),
>  GTK_WIDGET(grid));
> +gtk_grid_attach(grid, gtk_label_new("Resize the guest display:"), 0, 0, 
> 2, 1);
> +gtk_grid_attach(grid, enable_display, 0, 1, 1, 1);
> +gtk_grid_attach(grid, spin_id, 1, 1, 1, 1);
> +gtk_grid_attach(grid, gtk_label_new("width:"), 0, 2, 1, 1);
> +gtk_grid_attach(grid, spin_width, 1, 2, 1, 1);
> +gtk_grid_attach(grid, gtk_label_new("height:"), 0, 3, 1, 1);
> +gtk_grid_attach(grid, spin_height, 1, 3, 1, 1);
> +gtk_grid_attach(grid, gtk_label_new("x:"), 0, 4, 1, 1);
> +gtk_grid_attach(grid, spin_x, 1, 4, 1, 1);
> +gtk_grid_attach(grid, gtk_label_new("y:"), 0, 5, 1, 1);
> +gtk_grid_attach(grid, spin_y, 1, 5, 1, 1);
> +
> +gtk_widget_show_all(dialog);
> +if (gtk_dialog_run(GTK_DIALOG (dialog)) == GTK_RESPONSE_APPLY) {
> +spice_main_update_display_enabled(win->conn->main,
> +  
> gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_id)),
> +  
> gtk_switch_get_state(GTK_SWITCH(enable_display)),
> +  FALSE);
> +spice_main_set_display(win->conn->main,
> +   
> gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_id)),
> +   
> gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_x)),
> +   
> gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_y)),
> +   
> gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_width)),
> +   
> gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_height)));
> +spice_main_send_monitor_config(win->conn->main);
> +}
> +gtk_widget_destroy (dialog);
> +}
> +

OT: At some point we will need to move this UI part to css

Reviewed-by: Victor Toso 

>  static void restore_configuration(SpiceWindow *win)
>  {
>  gboolean state;
> @@ -692,6 +756,11 @@ static const GtkActionEntry entries[] = {
>  .callback= G_CALLBACK(menu_cb_fullscreen),
>  .accelerator = "F11",
>  },{
> +.name= "ResizeTo",
> +.label   = "_Resize to",
> +.callback= G_CALLBACK(menu_cb_resize_to),
> +.accelerator = "",
> +},{
>  #ifdef USE_SMARTCARD
>   .name= "I

Re: [Spice-devel] [spice-gtk v3 0/6] spice-channel: read/flush wire functions

[Victor Toso]

Hi,

Thanks for taking a look :)

On Thu, Mar 02, 2017 at 10:59:12AM +0100, Christophe Fergeau wrote:
> On Thu, Mar 02, 2017 at 10:23:45AM +0100, Victor Toso wrote:
> > Hi,
> >
> > On Tue, Feb 28, 2017 at 12:21:45PM +0100, Victor Toso wrote:
> > > From: Victor Toso 
> > >
> > > Hi,
> > >
> > > v2->v3:
> > > * Breaking spice_channel_read_wire() into smaller changes. (teuf)
> > >
> > > v2: 
> > > https://lists.freedesktop.org/archives/spice-devel/2017-February/035455.html
> > > v1: 
> > > https://lists.freedesktop.org/archives/spice-devel/2017-February/035446.html
> > >
> > > Cheers,
> > >
> > > Victor Toso (6):
> > >   spice-channel: move out non blocking logic of _read_wire()
> > >   spice-channel: move out non blocking logic of _flush_wire()
> > >   spice_channel_read_wire: prefer while(TRUE) instead of goto
> > >   spice_channel_read_wire: move variables to internal scope
> >
> > Any feedback on 3/6 and 4/6 ? I don't mind dropping the 5/6 and 6/6
> > patches at all. They don't bring much benefit and it might be just
> > personal preference.
>
> I was looking at this series yesterday, and I'm not really convinced it
> brings much, the while (TRUE) which is iterated once at most is as weird
> as the goto, before the patch the code is

We should only use goto to deal with errors or exceptions. Not sure why
here would be an exception.

https://www.spice-space.org/spice-project-coding-style-and-coding-conventions.html

> ret = 
> /* error handling depending on 'ret' value */
> if (ret == xxx) {
> } ...

This is 100% true but related to 5/6 and 6/6 which I'm totally fine in
dropping.

>
> /* nominal case */
>
> This series changes this to emphasize the 'read would block, retry', but
> does not really describe why this is better, the initial organization
> looks better to me.
>
> Christophe

This is in part of bigger change that I'm trying to have finished. With
this unfinished change, the channel might not be *allowed* to write/read
to give proper rate/bandwidth to higher priority channels (like
display/input).

In the situation above, we _could_ iterate in the loop more times.

I agree with you that this was not well explained. And I don't mind to
come back to this patches afterwards.

Thanks again for taking a look,
toso


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server] Release cursor as soon as possible

[Christophe Fergeau]

On Wed, Mar 01, 2017 at 11:54:20AM -0500, Frediano Ziglio wrote:
> > 
> > On Tue, Feb 28, 2017 at 03:20:09PM +, Frediano Ziglio wrote:
> > > Cursor resources (basically the shape of it) was retained till
> > > it was used however it was copied so there were no reason to not release
> > > this resource.
> > > 
> > > Signed-off-by: Frediano Ziglio 
> > > ---
> > >  server/cursor-channel.c | 14 --
> > >  server/cursor-channel.h |  4 ++--
> > >  server/red-parse-qxl.c  | 10 +++---
> > >  server/red-parse-qxl.h  |  4 ++--
> > >  server/red-worker.c |  5 +++--
> > >  server/tests/test-qxl-parsing.c | 26 +++---
> > >  6 files changed, 41 insertions(+), 22 deletions(-)
> > > 
> > > diff --git a/server/red-parse-qxl.c b/server/red-parse-qxl.c
> > > index 89cb120..5ed36df 100644
> > > --- a/server/red-parse-qxl.c
> > > +++ b/server/red-parse-qxl.c
> > > @@ -27,6 +27,7 @@
> > >  #include "red-common.h"
> > >  #include "memslot.h"
> > >  #include "red-parse-qxl.h"
> > > +#include "red-qxl.h"
> > >  
> > >  /* Max size in bytes for any data field used in a QXL command.
> > >   * This will for example be useful to prevent the guest from saturating
> > >   the
> > > @@ -1470,8 +1471,10 @@ static void red_put_cursor(SpiceCursor *red)
> > >  }
> > >  
> > >  int red_get_cursor_cmd(RedMemSlotInfo *slots, int group_id,
> > > -   RedCursorCmd *red, QXLPHYSICAL addr)
> > > +   RedCursorCmd *red, QXLPHYSICAL addr,
> > > +   QXLInstance *qxl_instance)
> > 
> > Not convinced about this patch, mainly I think because of the added
> > QXLInstance dependency which gets added to red-parse-qxl.h,
> > red_get_cursor_cmd() becoming odd compared to the other similar
> > functions, ...
> > 
> > I think it would work to have the red_qxl_release_resource() call in
> > red_process_cursor_cmd()?
> > 
> 
> This would be just a step before this...
> Memory management and resources are two sides of the coin.
> red-parse-qxl.c already deals with release_info information so
> adding a free is not really a big jump.
> Actually already some structures in red-parse-qxl.h has a QXLInstance
> which is initialized by red-worker.c. Maybe this is the issue, some
> structures are basically initialized half in red-parse-qxl.c and
> half in red-worker.c.

Dunno, but all the red_get_*_cmd() methods have a similar prototype, and
don't have a QXLInstance argument, changing this just for
red_get_cursor_cmd() makes it odd. Wrapping the QXLInstance together
with the command to release it more easily might make sense.

Looking through my old branches, I discovered some unfinished work doing
that /o\ Guess it's time to rebase it ;)

I'd prefer that we stick to the "step before this" (ie my suggestion)
until we can make this more consistent in red-parse-qxl.h

Christophe


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server 3/3] record: Allocate recording file globally from reds.c

[Frediano Ziglio]

Allows to use recording function for multiple purposes.
This will allow to register multiple screen VM or recording
additional stuff like sound.

Signed-off-by: Frediano Ziglio 
---
 server/red-worker.c   |  6 +-
 server/reds-private.h |  2 ++
 server/reds.c | 17 +
 server/reds.h |  5 +
 4 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/server/red-worker.c b/server/red-worker.c
index 93cb615..326e775 100644
--- a/server/red-worker.c
+++ b/server/red-worker.c
@@ -1312,7 +1312,6 @@ RedWorker* red_worker_new(QXLInstance *qxl,
 QXLDevInitInfo init_info;
 RedWorker *worker;
 Dispatcher *dispatcher;
-const char *record_filename;
 RedsState *reds = red_qxl_get_server(qxl->st);
 RedChannel *channel;
 
@@ -1322,10 +1321,7 @@ RedWorker* red_worker_new(QXLInstance *qxl,
 worker->core = event_loop_core;
 worker->core.main_context = g_main_context_new();
 
-record_filename = getenv("SPICE_WORKER_RECORD_FILENAME");
-if (record_filename) {
-worker->record = red_record_new(record_filename);
-}
+worker->record = reds_get_record(reds);
 dispatcher = red_qxl_get_dispatcher(qxl);
 dispatcher_set_opaque(dispatcher, worker);
 
diff --git a/server/reds-private.h b/server/reds-private.h
index e7e9ad7..07b7b38 100644
--- a/server/reds-private.h
+++ b/server/reds-private.h
@@ -25,6 +25,7 @@
 #include "main-channel.h"
 #include "inputs-channel.h"
 #include "stat-file.h"
+#include "red-record-qxl.h"
 
 #define MIGRATE_TIMEOUT (MSEC_PER_SEC * 10)
 #define MM_TIME_DELTA 400 /*ms*/
@@ -135,6 +136,7 @@ struct RedsState {
 SpiceCoreInterfaceInternal core;
 GList *qxl_instances;
 MainDispatcher *main_dispatcher;
+RedRecord *record;
 };
 
 #define FOREACH_QXL_INSTANCE(_reds, _iter, _qxl) \
diff --git a/server/reds.c b/server/reds.c
index f99dfda..9453a53 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3452,7 +3452,9 @@ static const char default_video_codecs[] = "spice:mjpeg;" 
GSTREAMER_CODECS;
 /* new interface */
 SPICE_GNUC_VISIBLE SpiceServer *spice_server_new(void)
 {
+const char *record_filename;
 RedsState *reds = spice_new0(RedsState, 1);
+
 reds->config = spice_new0(RedServerConfig, 1);
 reds->config->default_channel_security =
 SPICE_CHANNEL_SECURITY_NONE | SPICE_CHANNEL_SECURITY_SSL;
@@ -3484,6 +3486,12 @@ SPICE_GNUC_VISIBLE SpiceServer *spice_server_new(void)
 reds->listen_socket = -1;
 reds->secure_listen_socket = -1;
 
+/* This environment was in red-worker tso the "WORKER" in it.
+ * For compatibility reason we maintain the old name */
+record_filename = getenv("SPICE_WORKER_RECORD_FILENAME");
+if (record_filename) {
+reds->record = red_record_new(record_filename);
+}
 return reds;
 }
 
@@ -4519,3 +4527,12 @@ static RedCharDeviceVDIPort 
*red_char_device_vdi_port_new(RedsState *reds)
 "self-tokens", 
(guint64)REDS_NUM_INTERNAL_AGENT_MESSAGES,
 NULL);
 }
+
+RedRecord *reds_get_record(RedsState *reds)
+{
+if (reds->record) {
+return red_record_ref(reds->record);
+}
+
+return NULL;
+}
diff --git a/server/reds.h b/server/reds.h
index 28e3444..2748102 100644
--- a/server/reds.h
+++ b/server/reds.h
@@ -101,6 +101,11 @@ SpiceCoreInterfaceInternal* 
reds_get_core_interface(RedsState *reds);
 void reds_update_client_mouse_allowed(RedsState *reds);
 MainDispatcher* reds_get_main_dispatcher(RedsState *reds);
 
+/* Get the recording object stored in RedsState.
+ * You should free with red_record_unref.
+ */
+struct RedRecord *reds_get_record(RedsState *reds);
+
 /* fd watches/timers */
 SpiceWatch *reds_core_watch_add(RedsState *reds,
 int fd, int event_mask,
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server 2/3] record: Use reference counting for recording

[Frediano Ziglio]

Allows to share the recording object.

Signed-off-by: Frediano Ziglio 
---
 server/red-record-qxl.c | 19 ++-
 server/red-record-qxl.h |  3 ++-
 server/red-worker.c |  2 +-
 3 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/server/red-record-qxl.c b/server/red-record-qxl.c
index be6ac5a..e687c68 100644
--- a/server/red-record-qxl.c
+++ b/server/red-record-qxl.c
@@ -32,6 +32,7 @@ struct RedRecord {
 FILE *fd;
 pthread_mutex_t lock;
 unsigned int counter;
+gint refs;
 };
 
 #if 0
@@ -910,17 +911,25 @@ RedRecord *red_record_new(const char *filename)
 }
 
 record = g_new(RedRecord, 1);
+record->refs = 1;
 record->fd = f;
 record->counter = 0;
 pthread_mutex_init(&record->lock, NULL);
 return record;
 }
 
-void red_record_free(RedRecord *record)
+RedRecord *red_record_ref(RedRecord *record)
 {
-if (record) {
-fclose(record->fd);
-pthread_mutex_destroy(&record->lock);
-g_free(record);
+g_atomic_int_inc(&record->refs);
+return record;
+}
+
+void red_record_unref(RedRecord *record)
+{
+if (!record || !g_atomic_int_dec_and_test(&record->refs)) {
+return;
 }
+fclose(record->fd);
+pthread_mutex_destroy(&record->lock);
+g_free(record);
 }
diff --git a/server/red-record-qxl.h b/server/red-record-qxl.h
index 0685393..293e24a 100644
--- a/server/red-record-qxl.h
+++ b/server/red-record-qxl.h
@@ -33,7 +33,8 @@ typedef struct RedRecord RedRecord;
  */
 RedRecord* red_record_new(const char *filename);
 
-void red_record_free(RedRecord *record);
+RedRecord *red_record_ref(RedRecord *record);
+void red_record_unref(RedRecord *record);
 
 void red_record_primary_surface_create(RedRecord *record,
QXLDevSurfaceCreate *surface,
diff --git a/server/red-worker.c b/server/red-worker.c
index 8735cd1..93cb615 100644
--- a/server/red-worker.c
+++ b/server/red-worker.c
@@ -1461,7 +1461,7 @@ void red_worker_free(RedWorker *worker)
 g_main_context_unref(worker->core.main_context);
 
 if (worker->record) {
-red_record_free(worker->record);
+red_record_unref(worker->record);
 }
 memslot_info_destroy(&worker->mem_slots);
 free(worker);
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server 1/3] record: Synchronize write to record file

[Frediano Ziglio]

The synchronization code is required to avoid mixing writing
from multiple threads.
Following patches will add this feature.

Signed-off-by: Frediano Ziglio 
---
 server/red-record-qxl.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/server/red-record-qxl.c b/server/red-record-qxl.c
index ee22236..be6ac5a 100644
--- a/server/red-record-qxl.c
+++ b/server/red-record-qxl.c
@@ -30,6 +30,7 @@
 
 struct RedRecord {
 FILE *fd;
+pthread_mutex_t lock;
 unsigned int counter;
 };
 
@@ -794,15 +795,17 @@ void red_record_primary_surface_create(RedRecord *record,
 {
 FILE *fd = record->fd;
 
+pthread_mutex_lock(&record->lock);
 fprintf(fd, "%d %d %d %d\n", surface->width, surface->height,
 surface->stride, surface->format);
 fprintf(fd, "%d %d %d %d\n", surface->position, surface->mouse_mode,
 surface->flags, surface->type);
 write_binary(fd, "data", line_0 ? abs(surface->stride)*surface->height : 0,
 line_0);
+pthread_mutex_unlock(&record->lock);
 }
 
-void red_record_event(RedRecord *record, int what, uint32_t type)
+static void red_record_event_unlocked(RedRecord *record, int what, uint32_t 
type)
 {
 red_time_t ts = spice_get_monotonic_time_ns();
 // TODO: record the size of the packet in the header. This would make
@@ -813,12 +816,20 @@ void red_record_event(RedRecord *record, int what, 
uint32_t type)
 fprintf(record->fd, "event %u %d %u %"PRIu64"\n", record->counter++, what, 
type, ts);
 }
 
+void red_record_event(RedRecord *record, int what, uint32_t type)
+{
+pthread_mutex_lock(&record->lock);
+red_record_event_unlocked(record, what, type);
+pthread_mutex_unlock(&record->lock);
+}
+
 void red_record_qxl_command(RedRecord *record, RedMemSlotInfo *slots,
 QXLCommandExt ext_cmd)
 {
 FILE *fd = record->fd;
 
-red_record_event(record, 0, ext_cmd.cmd.type);
+pthread_mutex_lock(&record->lock);
+red_record_event_unlocked(record, 0, ext_cmd.cmd.type);
 
 switch (ext_cmd.cmd.type) {
 case QXL_CMD_DRAW:
@@ -837,6 +848,7 @@ void red_record_qxl_command(RedRecord *record, 
RedMemSlotInfo *slots,
 red_record_cursor_cmd(fd, slots, ext_cmd.group_id, ext_cmd.cmd.data);
 break;
 }
+pthread_mutex_unlock(&record->lock);
 }
 
 /**
@@ -900,6 +912,7 @@ RedRecord *red_record_new(const char *filename)
 record = g_new(RedRecord, 1);
 record->fd = f;
 record->counter = 0;
+pthread_mutex_init(&record->lock, NULL);
 return record;
 }
 
@@ -907,6 +920,7 @@ void red_record_free(RedRecord *record)
 {
 if (record) {
 fclose(record->fd);
+pthread_mutex_destroy(&record->lock);
 g_free(record);
 }
 }
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v2] spicy: keep status of mouse/agent on server mode

[Victor Toso]

Hi,

On Thu, Mar 02, 2017 at 10:48:23AM +0100, Christophe Fergeau wrote:
> missing log..

Sorry, I've improved it in the v3 (sending it with the other related
patches as well)

>
> Christophe
>
> On Thu, Mar 02, 2017 at 10:45:15AM +0100, Victor Toso wrote:
> > From: Victor Toso 
> > 
> > Signed-off-by: Victor Toso 
> > ---
> >  tools/spicy.c | 16 +---
> >  1 file changed, 9 insertions(+), 7 deletions(-)
> > 
> > diff --git a/tools/spicy.c b/tools/spicy.c
> > index ce6b40b..112312c 100644
> > --- a/tools/spicy.c
> > +++ b/tools/spicy.c
> > @@ -182,23 +182,25 @@ static int ask_user(GtkWidget *parent, char *title, 
> > char *message,
> >  
> >  static void update_status_window(SpiceWindow *win)
> >  {
> > -gchar *status;
> > +GString *status;
> >  
> >  if (win == NULL)
> >  return;
> >  
> > +status = g_string_new(NULL);
> > +g_string_printf(status, "mouse: %6s, agent: %3s",
> > +win->conn->mouse_state,
> > +win->conn->agent_state);
> > +
> >  if (win->mouse_grabbed) {
> >  SpiceGrabSequence *sequence = 
> > spice_display_get_grab_keys(SPICE_DISPLAY(win->spice));
> >  gchar *seq = spice_grab_sequence_as_string(sequence);
> > -status = g_strdup_printf("Use %s to ungrab mouse.", seq);
> > +g_string_append_printf(status, "\tUse %s to ungrab mouse", seq);
> >  g_free(seq);
> > -} else {
> > -status = g_strdup_printf("mouse: %s, agent: %s",
> > - win->conn->mouse_state, win->conn->agent_state);
> >  }
> >  
> > -gtk_label_set_text(GTK_LABEL(win->status), status);
> > -g_free(status);
> > +gtk_label_set_text(GTK_LABEL(win->status), status->str);
> > +g_string_free(status, TRUE);
> >  }
> >  
> >  static void update_status(struct spice_connection *conn)
> > -- 
> > 2.9.3
> > 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel




signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [spice-gtk v3 1/3] spicy: keep information on status label in server mode

[Victor Toso]

From: Victor Toso 

So we can still check the agent status while mouse is in server mode.

Signed-off-by: Victor Toso 
---
 tools/spicy.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/tools/spicy.c b/tools/spicy.c
index ce6b40b..112312c 100644
--- a/tools/spicy.c
+++ b/tools/spicy.c
@@ -182,23 +182,25 @@ static int ask_user(GtkWidget *parent, char *title, char 
*message,
 
 static void update_status_window(SpiceWindow *win)
 {
-gchar *status;
+GString *status;
 
 if (win == NULL)
 return;
 
+status = g_string_new(NULL);
+g_string_printf(status, "mouse: %6s, agent: %3s",
+win->conn->mouse_state,
+win->conn->agent_state);
+
 if (win->mouse_grabbed) {
 SpiceGrabSequence *sequence = 
spice_display_get_grab_keys(SPICE_DISPLAY(win->spice));
 gchar *seq = spice_grab_sequence_as_string(sequence);
-status = g_strdup_printf("Use %s to ungrab mouse.", seq);
+g_string_append_printf(status, "\tUse %s to ungrab mouse", seq);
 g_free(seq);
-} else {
-status = g_strdup_printf("mouse: %s, agent: %s",
- win->conn->mouse_state, win->conn->agent_state);
 }
 
-gtk_label_set_text(GTK_LABEL(win->status), status);
-g_free(status);
+gtk_label_set_text(GTK_LABEL(win->status), status->str);
+g_string_free(status, TRUE);
 }
 
 static void update_status(struct spice_connection *conn)
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [spice-gtk v3 3/3] spicy: improve status label with stream information

[Victor Toso]

From: Victor Toso 

By using stream-video-codec-type property, we can display which
video-codec is being used.

Signed-off-by: Victor Toso 
---
 tools/spicy.c | 43 +--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/tools/spicy.c b/tools/spicy.c
index 112312c..58e91f1 100644
--- a/tools/spicy.c
+++ b/tools/spicy.c
@@ -71,6 +71,7 @@ struct _SpiceWindow {
 bool fullscreen;
 bool mouse_grabbed;
 SpiceChannel *display_channel;
+gint video_codec;
 #ifdef G_OS_WIN32
 gint win_x;
 gint win_y;
@@ -180,6 +181,15 @@ static int ask_user(GtkWidget *parent, char *title, char 
*message,
 return retval;
 }
 
+static const gchar *video_codec_enum_to_str[] = {
+[0] = "none",
+[SPICE_VIDEO_CODEC_TYPE_MJPEG] = "mjpeg",
+[SPICE_VIDEO_CODEC_TYPE_VP8] = "vp8",
+[SPICE_VIDEO_CODEC_TYPE_H264] = "h264",
+[SPICE_VIDEO_CODEC_TYPE_VP9] = "vp9",
+[SPICE_VIDEO_CODEC_TYPE_ENUM_END] = "error",
+};
+
 static void update_status_window(SpiceWindow *win)
 {
 GString *status;
@@ -188,9 +198,10 @@ static void update_status_window(SpiceWindow *win)
 return;
 
 status = g_string_new(NULL);
-g_string_printf(status, "mouse: %6s, agent: %3s",
+g_string_printf(status, "mouse: %6s, agent: %3s, streaming: %5s",
 win->conn->mouse_state,
-win->conn->agent_state);
+win->conn->agent_state,
+video_codec_enum_to_str[win->video_codec]);
 
 if (win->mouse_grabbed) {
 SpiceGrabSequence *sequence = 
spice_display_get_grab_keys(SPICE_DISPLAY(win->spice));
@@ -1379,6 +1390,32 @@ static void del_window(spice_connection *conn, 
SpiceWindow *win)
 destroy_spice_window(win);
 }
 
+static void display_stream_changes(SpiceChannel *display, GParamSpec *pspec,
+   spice_connection *conn)
+{
+gint i;
+gint id, codec_type;
+GArray *monitors;
+
+g_object_get(display,
+ "channel-id", &id,
+ "monitors", &monitors,
+ "stream-video-codec-type", &codec_type,
+ NULL);
+
+for (i = 0; i < monitors->len; i++) {
+SpiceWindow *win = get_window(conn, id, i);
+
+if (win == NULL)
+continue;
+
+win->video_codec = codec_type;
+update_status_window(win);
+}
+
+g_clear_pointer(&monitors, g_array_unref);
+}
+
 static void display_monitors(SpiceChannel *display, GParamSpec *pspec,
  spice_connection *conn)
 {
@@ -1689,6 +1726,8 @@ static void channel_new(SpiceSession *s, SpiceChannel 
*channel, gpointer data)
 SPICE_DEBUG("new display channel (#%d)", id);
 g_signal_connect(channel, "notify::monitors",
  G_CALLBACK(display_monitors), conn);
+g_signal_connect(channel, "notify::stream-video-codec-type",
+ G_CALLBACK(display_stream_changes), conn);
 spice_channel_connect(channel);
 }
 
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [spice-gtk v3 2/3] channel-display: new stream-video-codec-type property

[Victor Toso]

From: Victor Toso 

This is a per channel-display property that stores and notifies the
video-codec type being used if a stream is being used or 0 if there is
no ongoing stream.

Signed-off-by: Victor Toso 
---
 src/channel-display.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/src/channel-display.c b/src/channel-display.c
index 7a5a23b..f30c7ed 100644
--- a/src/channel-display.c
+++ b/src/channel-display.c
@@ -70,6 +70,7 @@ struct _SpiceDisplayChannelPrivate {
 GArray  *monitors;
 guint   monitors_max;
 gbooleanenable_adaptive_streaming;
+SpiceVideoCodecType stream_video_codec_type;
 #ifdef G_OS_WIN32
 HDC dc;
 #endif
@@ -86,6 +87,7 @@ enum {
 PROP_MONITORS,
 PROP_MONITORS_MAX,
 PROP_GL_SCANOUT,
+PROP_STREAM_VIDEO_CODEC_TYPE,
 };
 
 enum {
@@ -222,6 +224,10 @@ static void spice_display_get_property(GObject*object,
 g_value_set_static_boxed(value, spice_display_get_gl_scanout(channel));
 break;
 }
+case PROP_STREAM_VIDEO_CODEC_TYPE: {
+g_value_set_int(value, c->stream_video_codec_type);
+break;
+}
 default:
 G_OBJECT_WARN_INVALID_PROPERTY_ID(object, prop_id, pspec);
 break;
@@ -335,6 +341,23 @@ static void 
spice_display_channel_class_init(SpiceDisplayChannelClass *klass)
 G_PARAM_STATIC_STRINGS));
 
 /**
+ * SpiceDisplayChannel:stream-video-codec-type
+ *
+ * The SpiceVideoCodecType enum value for the video-codec being used in the
+ * current stream or 0 when there is no ongoing streaming.
+ *
+ * Since: 0.34
+ */
+g_object_class_install_property
+(gobject_class, PROP_STREAM_VIDEO_CODEC_TYPE,
+ g_param_spec_int("stream-video-codec-type",
+  "Stream Video Codec Type",
+  "The Video Codec Type from current Stream",
+  0, SPICE_VIDEO_CODEC_TYPE_ENUM_END, 0,
+  G_PARAM_READABLE |
+  G_PARAM_STATIC_STRINGS));
+
+/**
  * SpiceDisplayChannel::display-primary-create:
  * @display: the #SpiceDisplayChannel that emitted the signal
  * @format: %SPICE_SURFACE_FMT_32_xRGB or %SPICE_SURFACE_FMT_16_555;
@@ -1218,6 +1241,10 @@ static void display_handle_stream_create(SpiceChannel 
*channel, SpiceMsgIn *in)
 spice_printerr("could not create a video decoder for codec %u", 
op->codec_type);
 destroy_stream(channel, op->id);
 report_invalid_stream(channel, op->id);
+} else {
+spice_debug("New stream created of type: %u", op->codec_type);
+c->stream_video_codec_type = op->codec_type;
+g_coroutine_object_notify(G_OBJECT(channel), 
"stream-video-codec-type");
 }
 }
 
@@ -1567,6 +1594,8 @@ static void destroy_stream(SpiceChannel *channel, int id)
 
 g_free(st);
 c->streams[id] = NULL;
+c->stream_video_codec_type = 0;
+g_coroutine_object_notify(G_OBJECT(channel), "stream-video-codec-type");
 }
 
 static void clear_streams(SpiceChannel *channel)
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [spice-gtk v3 0/3] channel-display with new stream-video-codec property

[Victor Toso]

From: Victor Toso 

Hi,

The main idea is to be able to easily see the video-codec changing.
Spicy uses thes new property and set the information in its status label.

v1->v3:
* (1/3) Don't need to use #defines in the string messages (Jonathon)
* (1/3) Improve commit log

Victor Toso (3):
  spicy: keep information on status label in server mode
  channel-display: new stream-video-codec-type property
  spicy: improve status label with stream information

 src/channel-display.c | 29 +++
 tools/spicy.c | 55 ---
 2 files changed, 77 insertions(+), 7 deletions(-)
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk v3] Switch over to using keycodemapdb submodule

[Daniel P. Berrange]

On Thu, Mar 02, 2017 at 07:59:42AM +0100, Pavel Grunt wrote:
> On Mon, 2017-02-27 at 10:44 +, Daniel P. Berrange wrote:
> > On Mon, Feb 27, 2017 at 11:37:44AM +0100, Pavel Grunt wrote:
> > > Hello Daniel,
> > > 
> > > On Mon, 2017-02-27 at 10:25 +, Daniel P. Berrange wrote:
> > > > Consume the keymaps.csv file from a git submodule instead of
> > > > having
> > > > a private copy. This makes it easier to ensure all users of the
> > > > keymap
> > > > (libvirt, gtk-vnc, spice-gtk, and eventually QEMU) to have a
> > > > consistent
> > > > set of data.
> > > > 
> > > 
> > > besides that it also allow us to drop the dependency on perl (also
> > > perl-Text-CSV is not packaged in some distros)
> > 
> > True yes, I intentionally kept the python code so that it only
> > used modules base-python installs so we don't rely on external
> > modules from pypi.
> > 
> > > Are there contributing rules for the keycodemapdb (where to send
> > > the
> > > patches etc.)?
> > 
> > Just send pull requests to the repo is best I think. I don't think
> > we'd
> > have enough traffic to warrant creating a new mailing list. In any
> > case I would expect that most bug reports would start off with a
> > mail
> > and/or bug report to a project using the module. eg a mail on spice-
> > devel,
> > so there's little point trying to artificially move discussion to a
> > dedicated list.
> > 
> > I'm happy to add any of the people with experiance of this code to
> > the
> > admins/committers list of the gitlab project too, so I'm not a
> > potential
> > bottleneck.
> Feel free to add me (nickname "xerus")

Ok, I added you as co-owner to increase the bus factor

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH v4] Switch over to using keycodemapdb submodule

[Daniel P. Berrange]

Consume the keymaps.csv file from a git submodule instead of having
a private copy. This makes it easier to ensure all users of the keymap
(libvirt, gtk-vnc, spice-gtk, and eventually QEMU) to have a consistent
set of data.

Signed-off-by: Daniel P. Berrange 
---

Changed in v4:

  - Use correct submodule commit to fix OSX keymaps

 .gitmodules   |   3 +
 configure.ac  |  11 --
 src/Makefile.am   |  30 ++--
 src/keycodemapdb  |   1 +
 src/keymap-gen.pl | 214 ---
 src/keymaps.csv   | 511 --
 6 files changed, 17 insertions(+), 753 deletions(-)
 create mode 16 src/keycodemapdb
 delete mode 100755 src/keymap-gen.pl
 delete mode 100644 src/keymaps.csv

diff --git a/.gitmodules b/.gitmodules
index 0c618ee..82467e4 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,3 +1,6 @@
 [submodule "spice-common"]
path = spice-common
url = ../spice-common
+[submodule "src/keycodemapdb"]
+   path = src/keycodemapdb
+   url = https://gitlab.com/keycodemap/keycodemapdb.git
diff --git a/configure.ac b/configure.ac
index 463fbe0..763d14b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -86,17 +86,6 @@ AC_SUBST(SPICE_GTK_MICRO_VERSION)
 dnl =
 dnl Chek optional features
 
-srcdir="$(dirname $0)"
-if test ! -e "$srcdir/src/vncdisplaykeymap_osx2xtkbd.c"; then
-  AC_MSG_CHECKING([for Text::CSV Perl module])
-  perl -MText::CSV -e "" >/dev/null 2>&1
-  if test $? -ne 0 ; then
-AC_MSG_RESULT([not found])
-AC_MSG_ERROR([Text::CSV Perl module is required to compile this package])
-  fi
-  AC_MSG_RESULT([found])
-fi
-
 SPICE_GLIB_REQUIRES=""
 SPICE_GTK_REQUIRES=""
 
diff --git a/src/Makefile.am b/src/Makefile.am
index 7542fac..594c0de 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -26,14 +26,13 @@ GLIBGENS =  \
spice-widget-enums.h\
$(NULL)
 
-CLEANFILES = $(GLIBGENS)
+CLEANFILES = $(GLIBGENS) $(KEYMAPS)
 BUILT_SOURCES = $(GLIBGENS) $(KEYMAPS)
 
 EXTRA_DIST =   \
-   $(KEYMAPS)  \
decode-glz-tmpl.c   \
-   keymap-gen.pl   \
-   keymaps.csv \
+   $(KEYMAP_CSV)   \
+   $(KEYMAP_GEN)   \
map-file\
spice-glib-sym-file \
spice-gtk-sym-file  \
@@ -66,7 +65,8 @@ GTK_SYMBOLS_LDFLAGS = -export-symbols 
${srcdir}/spice-gtk-sym-file
 GTK_SYMBOLS_FILE = spice-gtk-sym-file
 endif
 
-KEYMAP_GEN = $(srcdir)/keymap-gen.pl
+KEYMAP_GEN = keycodemapdb/tools/keymap-gen
+KEYMAP_CSV = keycodemapdb/data/keymaps.csv
 
 SPICE_COMMON_CPPFLAGS =\
-DSPICE_COMPILATION \
@@ -483,32 +483,28 @@ spice-widget-enums.h: spice-widget.h
 
 
 vncdisplaykeymap.c: $(KEYMAPS)
+$(KEYMAPS): $(srcdir)/$(KEYMAP_GEN) $(srcdir)/$(KEYMAP_CSV)
 
-$(KEYMAPS): $(KEYMAP_GEN) keymaps.csv
-
-# Note despite being autogenerated these are not part of CLEANFILES, they
-# are actually a part of EXTRA_DIST to avoid the need for perl(Text::CSV) by
-# end users
 vncdisplaykeymap_xorgevdev2xtkbd.c:
-   $(AM_V_GEN)$(KEYMAP_GEN) $(srcdir)/keymaps.csv xorgevdev xtkbd > $@ || 
rm $@
+   $(AM_V_GEN)$(PYTHON) $(srcdir)/$(KEYMAP_GEN) --lang glib2 --varname 
keymap_xorgevdev2xtkbd code-map $(srcdir)/$(KEYMAP_CSV) xorgevdev xtkbd > $@ || 
rm $@
 
 vncdisplaykeymap_xorgkbd2xtkbd.c:
-   $(AM_V_GEN)$(KEYMAP_GEN) $(srcdir)/keymaps.csv xorgkbd xtkbd > $@ || rm 
$@
+   $(AM_V_GEN)$(PYTHON) $(srcdir)/$(KEYMAP_GEN) --lang glib2 --varname 
keymap_xorgkbd2xtkbd code-map $(srcdir)/$(KEYMAP_CSV) xorgkbd xtkbd > $@ || rm 
$@
 
 vncdisplaykeymap_xorgxquartz2xtkbd.c:
-   $(AM_V_GEN)$(KEYMAP_GEN) $(srcdir)/keymaps.csv xorgxquartz xtkbd > $@ 
|| rm $@
+   $(AM_V_GEN)$(PYTHON) $(srcdir)/$(KEYMAP_GEN) --lang glib2 --varname 
keymap_xorgxquartz2xtkbd code-map $(srcdir)/$(KEYMAP_CSV) xorgxquartz xtkbd > 
$@ || rm $@
 
 vncdisplaykeymap_xorgxwin2xtkbd.c:
-   $(AM_V_GEN)$(KEYMAP_GEN) $(srcdir)/keymaps.csv xorgxwin xtkbd > $@ || 
rm $@
+   $(AM_V_GEN)$(PYTHON) $(srcdir)/$(KEYMAP_GEN) --lang glib2 --varname 
keymap_xorgxwin2xtkbd code-map $(srcdir)/$(KEYMAP_CSV) xorgxwin xtkbd > $@ || 
rm $@
 
 vncdisplaykeymap_osx2xtkbd.c:
-   $(AM_V_GEN)$(KEYMAP_GEN) $(srcdir)/keymaps.csv osx xtkbd > $@ || rm $@
+   $(AM_V_GEN)$(PYTHON) $(srcdir)/$(KEYMAP_GEN) --lang glib2 --varname 
keymap_osx2xtkbd code-map $(srcdir)/$(KEYMAP_CSV) osx xtkbd > $@ || rm $@
 
 vncdisplaykeymap_win322xtkbd.c:
-   $(AM_V_GEN)$(KEYMAP_GEN) $(srcdir)/keymaps.csv win32 xtkbd > $@ || rm $@
+   $(AM_V_GEN)$(PYTHON) $(srcdir)/$(KEYMAP_GEN) --lang glib2 --varname 
keymap_win322xtkbd co

Re: [Spice-devel] [PATCH spice-gtk v3] Switch over to using keycodemapdb submodule

[Daniel P. Berrange]

On Thu, Mar 02, 2017 at 08:16:15AM +0100, Pavel Grunt wrote:
> On Thu, 2017-03-02 at 07:59 +0100, Pavel Grunt wrote:
> > On Mon, 2017-02-27 at 10:44 +, Daniel P. Berrange wrote:
> > > On Mon, Feb 27, 2017 at 11:37:44AM +0100, Pavel Grunt wrote:
> > > > Hello Daniel,
> > > > 
> > > > On Mon, 2017-02-27 at 10:25 +, Daniel P. Berrange wrote:
> > > > > Consume the keymaps.csv file from a git submodule instead of
> > > > > having
> > > > > a private copy. This makes it easier to ensure all users of
> > > > > the
> > > > > keymap
> > > > > (libvirt, gtk-vnc, spice-gtk, and eventually QEMU) to have a
> > > > > consistent
> > > > > set of data.
> > > > > 
> > > > 
> > > > besides that it also allow us to drop the dependency on perl
> > > > (also
> > > > perl-Text-CSV is not packaged in some distros)
> > > 
> > > True yes, I intentionally kept the python code so that it only
> > > used modules base-python installs so we don't rely on external
> > > modules from pypi.
> > > 
> > > > Are there contributing rules for the keycodemapdb (where to send
> > > > the
> > > > patches etc.)?
> > > 
> > > Just send pull requests to the repo is best I think. I don't think
> > > we'd
> > > have enough traffic to warrant creating a new mailing list. In any
> > > case I would expect that most bug reports would start off with a
> > > mail
> > > and/or bug report to a project using the module. eg a mail on
> > > spice-
> > > devel,
> > > so there's little point trying to artificially move discussion to
> > > a
> > > dedicated list.
> > > 
> > > I'm happy to add any of the people with experiance of this code to
> > > the
> > > admins/committers list of the gitlab project too, so I'm not a
> > > potential
> > > bottleneck.
> > 
> > Feel free to add me (nickname "xerus")
> > 
> > > 
> > > > (For the future) Do you consider adding the
> > > > vncdisplaykeymap.[ch]
> > > > to
> > > > the repo ?
> > > 
> > > I'm unsure of the direction to take for that at this time. It
> > > would
> > > certainly be interesting to look at sharing that logic. For
> > > sharing
> > > code though, I wonder if its better to create a
> > > libgtkkeycodemap.so
> > > library rather than do a sub-module thing for that code too.
> > 
> > we have both ways in spice-common
> > 
> > About the patch - the generated file are not the same (I used git
> > diff
> > --word-diff)
> > 
> > xorgkbd2xtkbd - empty
> > xorgxquartz2xtkbd - some values are different
> > 
> > Pavel
> > 
> > https://paste.fedoraproject.org/paste/N9n1q2y3dZHDNhMOaIA5c15M1UNdIG
> > Yh
> > yRLivL9gydE=
> > 
> Ok, I see it is fixed in the current git master (this submodule is one
> commit behind)

Yes, just verified that accounts for the difference you see - i'll send
a new patch.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk v3] Switch over to using keycodemapdb submodule

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 08:16:15AM +0100, Pavel Grunt wrote:
> On Thu, 2017-03-02 at 07:59 +0100, Pavel Grunt wrote:
> > On Mon, 2017-02-27 at 10:44 +, Daniel P. Berrange wrote:
> > > On Mon, Feb 27, 2017 at 11:37:44AM +0100, Pavel Grunt wrote:
> > > > Hello Daniel,
> > > > 
> > > > On Mon, 2017-02-27 at 10:25 +, Daniel P. Berrange wrote:
> > > > > Consume the keymaps.csv file from a git submodule instead of
> > > > > having
> > > > > a private copy. This makes it easier to ensure all users of
> > > > > the
> > > > > keymap
> > > > > (libvirt, gtk-vnc, spice-gtk, and eventually QEMU) to have a
> > > > > consistent
> > > > > set of data.
> > > > > 
> > > > 
> > > > besides that it also allow us to drop the dependency on perl
> > > > (also
> > > > perl-Text-CSV is not packaged in some distros)
> > > 
> > > True yes, I intentionally kept the python code so that it only
> > > used modules base-python installs so we don't rely on external
> > > modules from pypi.
> > > 
> > > > Are there contributing rules for the keycodemapdb (where to send
> > > > the
> > > > patches etc.)?
> > > 
> > > Just send pull requests to the repo is best I think. I don't think
> > > we'd
> > > have enough traffic to warrant creating a new mailing list. In any
> > > case I would expect that most bug reports would start off with a
> > > mail
> > > and/or bug report to a project using the module. eg a mail on
> > > spice-
> > > devel,
> > > so there's little point trying to artificially move discussion to
> > > a
> > > dedicated list.
> > > 
> > > I'm happy to add any of the people with experiance of this code to
> > > the
> > > admins/committers list of the gitlab project too, so I'm not a
> > > potential
> > > bottleneck.
> > 
> > Feel free to add me (nickname "xerus")
> > 
> > > 
> > > > (For the future) Do you consider adding the
> > > > vncdisplaykeymap.[ch]
> > > > to
> > > > the repo ?
> > > 
> > > I'm unsure of the direction to take for that at this time. It
> > > would
> > > certainly be interesting to look at sharing that logic. For
> > > sharing
> > > code though, I wonder if its better to create a
> > > libgtkkeycodemap.so
> > > library rather than do a sub-module thing for that code too.
> > 
> > we have both ways in spice-common
> > 
> > About the patch - the generated file are not the same (I used git
> > diff
> > --word-diff)
> > 
> > xorgkbd2xtkbd - empty
> > xorgxquartz2xtkbd - some values are different
> > 
> > Pavel
> > 
> > https://paste.fedoraproject.org/paste/N9n1q2y3dZHDNhMOaIA5c15M1UNdIG
> > Yh
> > yRLivL9gydE=
> > 
> Ok, I see it is fixed in the current git master (this submodule is one
> commit behind)
> 
> Ack from me with that fixed.
> Any other opinion about adding or not the submodule ?

I did not look at the submodule in details, but having the keymaps in a
submodule makes sense to me.

Christophe


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v3 0/6] spice-channel: read/flush wire functions

[Christophe Fergeau]

On Thu, Mar 02, 2017 at 10:23:45AM +0100, Victor Toso wrote:
> Hi,
> 
> On Tue, Feb 28, 2017 at 12:21:45PM +0100, Victor Toso wrote:
> > From: Victor Toso 
> > 
> > Hi,
> > 
> > v2->v3:
> > * Breaking spice_channel_read_wire() into smaller changes. (teuf)
> > 
> > v2: 
> > https://lists.freedesktop.org/archives/spice-devel/2017-February/035455.html
> > v1: 
> > https://lists.freedesktop.org/archives/spice-devel/2017-February/035446.html
> > 
> > Cheers,
> > 
> > Victor Toso (6):
> >   spice-channel: move out non blocking logic of _read_wire()
> >   spice-channel: move out non blocking logic of _flush_wire()
> >   spice_channel_read_wire: prefer while(TRUE) instead of goto
> >   spice_channel_read_wire: move variables to internal scope
> 
> Any feedback on 3/6 and 4/6 ? I don't mind dropping the 5/6 and 6/6
> patches at all. They don't bring much benefit and it might be just
> personal preference.

I was looking at this series yesterday, and I'm not really convinced it
brings much, the while (TRUE) which is iterated once at most is as weird
as the goto, before the patch the code is
ret = 
/* error handling depending on 'ret' value */
if (ret == xxx) {
} ...

/* nominal case */


This series changes this to emphasize the 'read would block, retry', but
does not really describe why this is better, the initial organization
looks better to me.

Christophe


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] spicy: Add dialog for precise resizing

[Pavel Grunt]

It helps when testing whether the guest resizes to requested resolution

Also it gives spicy a basic multimonitor support
---
 tools/spicy.c | 72 +++
 1 file changed, 72 insertions(+)

diff --git a/tools/spicy.c b/tools/spicy.c
index ce6b40b..83ce6d5 100644
--- a/tools/spicy.c
+++ b/tools/spicy.c
@@ -566,6 +566,70 @@ static void keyboard_grab_cb(GtkWidget *widget, gint 
grabbed, gpointer data)
 }
 }
 
+static void menu_cb_resize_to(GtkAction *action G_GNUC_UNUSED,
+  gpointer data)
+{
+SpiceWindow *win = data;
+GtkWidget *dialog, *enable_display;
+GtkWidget *spin_width, *spin_height, *spin_x, *spin_y, *spin_id;
+GtkGrid *grid;
+gint width, height;
+dialog = gtk_dialog_new_with_buttons("Resize guest to",
+ GTK_WINDOW(win->toplevel),
+ GTK_DIALOG_DESTROY_WITH_PARENT,
+ "_Apply",
+ GTK_RESPONSE_APPLY,
+ "_Cancel",
+ GTK_RESPONSE_CANCEL,
+ NULL);
+
+enable_display = gtk_switch_new();
+gtk_switch_set_state(GTK_SWITCH(enable_display), TRUE);
+
+spin_width = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
+spin_height = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
+spin_x = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
+spin_y = gtk_spin_button_new_with_range(0, G_MAXINT, 10);
+spin_id = gtk_spin_button_new_with_range(0, CHANNELID_MAX * MONITORID_MAX 
- 1, 1);
+
+gtk_widget_get_preferred_width(win->spice, NULL, &width);
+gtk_widget_get_preferred_height(win->spice, NULL, &height);
+
+gtk_spin_button_set_value(GTK_SPIN_BUTTON(spin_width), width);
+gtk_spin_button_set_value(GTK_SPIN_BUTTON(spin_height), height);
+gtk_spin_button_set_value(GTK_SPIN_BUTTON(spin_id), win->id + 
win->monitor_id);
+
+grid = GTK_GRID(gtk_grid_new());
+
gtk_container_add(GTK_CONTAINER(gtk_dialog_get_content_area(GTK_DIALOG(dialog))),
 GTK_WIDGET(grid));
+gtk_grid_attach(grid, gtk_label_new("Resize the guest display:"), 0, 0, 2, 
1);
+gtk_grid_attach(grid, enable_display, 0, 1, 1, 1);
+gtk_grid_attach(grid, spin_id, 1, 1, 1, 1);
+gtk_grid_attach(grid, gtk_label_new("width:"), 0, 2, 1, 1);
+gtk_grid_attach(grid, spin_width, 1, 2, 1, 1);
+gtk_grid_attach(grid, gtk_label_new("height:"), 0, 3, 1, 1);
+gtk_grid_attach(grid, spin_height, 1, 3, 1, 1);
+gtk_grid_attach(grid, gtk_label_new("x:"), 0, 4, 1, 1);
+gtk_grid_attach(grid, spin_x, 1, 4, 1, 1);
+gtk_grid_attach(grid, gtk_label_new("y:"), 0, 5, 1, 1);
+gtk_grid_attach(grid, spin_y, 1, 5, 1, 1);
+
+gtk_widget_show_all(dialog);
+if (gtk_dialog_run(GTK_DIALOG (dialog)) == GTK_RESPONSE_APPLY) {
+spice_main_update_display_enabled(win->conn->main,
+  
gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_id)),
+  
gtk_switch_get_state(GTK_SWITCH(enable_display)),
+  FALSE);
+spice_main_set_display(win->conn->main,
+   
gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_id)),
+   
gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_x)),
+   
gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_y)),
+   
gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_width)),
+   
gtk_spin_button_get_value_as_int(GTK_SPIN_BUTTON(spin_height)));
+spice_main_send_monitor_config(win->conn->main);
+}
+gtk_widget_destroy (dialog);
+}
+
 static void restore_configuration(SpiceWindow *win)
 {
 gboolean state;
@@ -692,6 +756,11 @@ static const GtkActionEntry entries[] = {
 .callback= G_CALLBACK(menu_cb_fullscreen),
 .accelerator = "F11",
 },{
+.name= "ResizeTo",
+.label   = "_Resize to",
+.callback= G_CALLBACK(menu_cb_resize_to),
+.accelerator = "",
+},{
 #ifdef USE_SMARTCARD
.name= "InsertSmartcard",
.label   = "_Insert Smartcard",
@@ -905,6 +974,9 @@ static char ui_xml[] =
 "\n"
 "\n"
 "\n"
+"\n"
+"\n"
+"\n"
 "  \n"
 "\n";
 
-- 
2.12.0

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v2] spicy: keep status of mouse/agent on server mode

[Christophe Fergeau]

missing log..

Christophe

On Thu, Mar 02, 2017 at 10:45:15AM +0100, Victor Toso wrote:
> From: Victor Toso 
> 
> Signed-off-by: Victor Toso 
> ---
>  tools/spicy.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/spicy.c b/tools/spicy.c
> index ce6b40b..112312c 100644
> --- a/tools/spicy.c
> +++ b/tools/spicy.c
> @@ -182,23 +182,25 @@ static int ask_user(GtkWidget *parent, char *title, 
> char *message,
>  
>  static void update_status_window(SpiceWindow *win)
>  {
> -gchar *status;
> +GString *status;
>  
>  if (win == NULL)
>  return;
>  
> +status = g_string_new(NULL);
> +g_string_printf(status, "mouse: %6s, agent: %3s",
> +win->conn->mouse_state,
> +win->conn->agent_state);
> +
>  if (win->mouse_grabbed) {
>  SpiceGrabSequence *sequence = 
> spice_display_get_grab_keys(SPICE_DISPLAY(win->spice));
>  gchar *seq = spice_grab_sequence_as_string(sequence);
> -status = g_strdup_printf("Use %s to ungrab mouse.", seq);
> +g_string_append_printf(status, "\tUse %s to ungrab mouse", seq);
>  g_free(seq);
> -} else {
> -status = g_strdup_printf("mouse: %s, agent: %s",
> - win->conn->mouse_state, win->conn->agent_state);
>  }
>  
> -gtk_label_set_text(GTK_LABEL(win->status), status);
> -g_free(status);
> +gtk_label_set_text(GTK_LABEL(win->status), status->str);
> +g_string_free(status, TRUE);
>  }
>  
>  static void update_status(struct spice_connection *conn)
> -- 
> 2.9.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [spice-gtk v2] spicy: keep status of mouse/agent on server mode

[Victor Toso]

From: Victor Toso 

Signed-off-by: Victor Toso 
---
 tools/spicy.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/tools/spicy.c b/tools/spicy.c
index ce6b40b..112312c 100644
--- a/tools/spicy.c
+++ b/tools/spicy.c
@@ -182,23 +182,25 @@ static int ask_user(GtkWidget *parent, char *title, char 
*message,
 
 static void update_status_window(SpiceWindow *win)
 {
-gchar *status;
+GString *status;
 
 if (win == NULL)
 return;
 
+status = g_string_new(NULL);
+g_string_printf(status, "mouse: %6s, agent: %3s",
+win->conn->mouse_state,
+win->conn->agent_state);
+
 if (win->mouse_grabbed) {
 SpiceGrabSequence *sequence = 
spice_display_get_grab_keys(SPICE_DISPLAY(win->spice));
 gchar *seq = spice_grab_sequence_as_string(sequence);
-status = g_strdup_printf("Use %s to ungrab mouse.", seq);
+g_string_append_printf(status, "\tUse %s to ungrab mouse", seq);
 g_free(seq);
-} else {
-status = g_strdup_printf("mouse: %s, agent: %s",
- win->conn->mouse_state, win->conn->agent_state);
 }
 
-gtk_label_set_text(GTK_LABEL(win->status), status);
-g_free(status);
+gtk_label_set_text(GTK_LABEL(win->status), status->str);
+g_string_free(status, TRUE);
 }
 
 static void update_status(struct spice_connection *conn)
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] How to send a custom resolution message to windows/linux guest vdagent

[Victor Toso]

Hi,

On Thu, Mar 02, 2017 at 10:32:30AM +0100, Pavel Grunt wrote:
> Actually I sent a patch for it few months ago ;)
> https://github.com/xerus/spice-gtk/commit/2fbf5aaed4adec593a5e89e93d3b
> 286b98816419

Yay, mind to rebase and send again?


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] How to send a custom resolution message to windows/linux guest vdagent

[Pavel Grunt]

On Thu, 2017-03-02 at 10:18 +0100, Victor Toso wrote:
> Oi Thiago,
> 
> On Thu, Mar 02, 2017 at 03:58:34AM -0300, Thiago Nascimento Araujo
> wrote:
> > Hello,
> > 
> > Is there a way to send a spice message, connect to pipe, or any
> > other
> > method to contact vdservice/vdagent to create/simulate a resize to
> > an
> > arbitrary resolution or full screen effect caused by remote-
> > viewer?
> 
> I would start enabling the debug messages, it should give you good
> hints
> on how things work. For instance, with spicy --spice-debug:
> 
> /* Resizing the widget */
> GSpice-DEBUG: spice-widget.c:1228 recalc geom monitor: 0:0, guest
> +0+0:640x480, window 714x522, zoom 1
> GSpice-DEBUG: spice-widget.c:1228 recalc geom monitor: 0:0, guest
> +0+0:640x480, window 715x524, zoom 1
> GSpice-DEBUG: spice-widget.c:1228 recalc geom monitor: 0:0, guest
> +0+0:640x480, window 716x525, zoom 1
> (...)
> GSpice-DEBUG: spice-widget.c:1810 focus_in_event
> GSpice-DEBUG: spice-widget.c:1462 release_keys
> GSpice-DEBUG: spice-gtk-session.c:203 inputs-3:0:
> client_modifiers:0x2, guest_modifiers:0x2
> /* Sending new monitors config! */
> GSpice-DEBUG: channel-main.c:1118 main-1:0: sending new monitors
> config to guest
> GSpice-DEBUG: channel-main.c:1135 main-1:0: monitor #0: 716x525+0+0
> @ 32 bpp
> GSpice-DEBUG: channel-main.c:1070 #0 +0+0-716x525
> GSpice-DEBUG: channel-display.c:1820 display-2:0: received empty
> monitor config
> GSpice-DEBUG: channel-display.c:1820 display-2:0: received empty
> monitor config
> GSpice-DEBUG: channel-display.c:1820 display-2:0: received empty
> monitor config
> GSpice-DEBUG: channel-display.c:1820 display-2:0: received empty
> monitor config
> /* Done with the interesting part */
> 
> Very likely it should be possible to improve the spicy testing tool
> to
> have something that could you help you test it, like some text
> fields to
> set display X width X height values.

Actually I sent a patch for it few months ago ;)
https://github.com/xerus/spice-gtk/commit/2fbf5aaed4adec593a5e89e93d3b
286b98816419


> 
> > Any other ways I can connect to the named pipes (windows guests or
> > linux guests) and watch/debug/learn. I cant find or connect to the
> > windows guest named pipe and I got connection refused trying to
> > socat
> > to a port in linux guest.
> 
> You will then need to hexdump the data and start trying to get the
> meaning out of it. I think it is more interesting to include more
> debug
> in the agents if you want to know more specific details about
> something
> that is going on. Or even gdb -p $PID.
> 
> > I really need some guidance to fully understand how arbitrary
> > resolutions are created using win/lnx/spice api.
> > 
> > Thanks in advance.
> 
> Feel free to ask your doubts here as well. We would gladly take any
> patches that improve the documentation/testing tools too :)
> 
> toso
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v3 0/6] spice-channel: read/flush wire functions

[Victor Toso]

Hi,

On Tue, Feb 28, 2017 at 12:21:45PM +0100, Victor Toso wrote:
> From: Victor Toso 
> 
> Hi,
> 
> v2->v3:
> * Breaking spice_channel_read_wire() into smaller changes. (teuf)
> 
> v2: 
> https://lists.freedesktop.org/archives/spice-devel/2017-February/035455.html
> v1: 
> https://lists.freedesktop.org/archives/spice-devel/2017-February/035446.html
> 
> Cheers,
> 
> Victor Toso (6):
>   spice-channel: move out non blocking logic of _read_wire()
>   spice-channel: move out non blocking logic of _flush_wire()
>   spice_channel_read_wire: prefer while(TRUE) instead of goto
>   spice_channel_read_wire: move variables to internal scope

Any feedback on 3/6 and 4/6 ? I don't mind dropping the 5/6 and 6/6
patches at all. They don't bring much benefit and it might be just
personal preference.

Cheers!

>   spice_channel_read_wire: return earlier whenever is possible
>   spice_channel_flush_wire: make it similar to _read_wire()
> 
>  src/spice-channel.c | 172 
> +---
>  1 file changed, 108 insertions(+), 64 deletions(-)
> 
> --
> 2.9.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] How to send a custom resolution message to windows/linux guest vdagent

[Victor Toso]

Oi Thiago,

On Thu, Mar 02, 2017 at 03:58:34AM -0300, Thiago Nascimento Araujo wrote:
> Hello,
>
> Is there a way to send a spice message, connect to pipe, or any other
> method to contact vdservice/vdagent to create/simulate a resize to an
> arbitrary resolution or full screen effect caused by remote-viewer?

I would start enabling the debug messages, it should give you good hints
on how things work. For instance, with spicy --spice-debug:

/* Resizing the widget */
GSpice-DEBUG: spice-widget.c:1228 recalc geom monitor: 0:0, guest +0+0:640x480, 
window 714x522, zoom 1
GSpice-DEBUG: spice-widget.c:1228 recalc geom monitor: 0:0, guest +0+0:640x480, 
window 715x524, zoom 1
GSpice-DEBUG: spice-widget.c:1228 recalc geom monitor: 0:0, guest +0+0:640x480, 
window 716x525, zoom 1
(...)
GSpice-DEBUG: spice-widget.c:1810 focus_in_event
GSpice-DEBUG: spice-widget.c:1462 release_keys
GSpice-DEBUG: spice-gtk-session.c:203 inputs-3:0: client_modifiers:0x2, 
guest_modifiers:0x2
/* Sending new monitors config! */
GSpice-DEBUG: channel-main.c:1118 main-1:0: sending new monitors config to guest
GSpice-DEBUG: channel-main.c:1135 main-1:0: monitor #0: 716x525+0+0 @ 32 bpp
GSpice-DEBUG: channel-main.c:1070 #0 +0+0-716x525
GSpice-DEBUG: channel-display.c:1820 display-2:0: received empty monitor config
GSpice-DEBUG: channel-display.c:1820 display-2:0: received empty monitor config
GSpice-DEBUG: channel-display.c:1820 display-2:0: received empty monitor config
GSpice-DEBUG: channel-display.c:1820 display-2:0: received empty monitor config
/* Done with the interesting part */

Very likely it should be possible to improve the spicy testing tool to
have something that could you help you test it, like some text fields to
set display X width X height values.

> Any other ways I can connect to the named pipes (windows guests or
> linux guests) and watch/debug/learn. I cant find or connect to the
> windows guest named pipe and I got connection refused trying to socat
> to a port in linux guest.

You will then need to hexdump the data and start trying to get the
meaning out of it. I think it is more interesting to include more debug
in the agents if you want to know more specific details about something
that is going on. Or even gdb -p $PID.

> I really need some guidance to fully understand how arbitrary
> resolutions are created using win/lnx/spice api.
>
> Thanks in advance.

Feel free to ask your doubts here as well. We would gladly take any
patches that improve the documentation/testing tools too :)

toso


signature.asc
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server v3 0/5] Change the way we pass capabilities

[Frediano Ziglio]

This patchset attempt to pass capabilities using a single
RedChannelCapabilities (already existing) structure.

Changes since v2:
- merge GArray and RedChannelCapabilites usage;
- split removing reading capability properties;
- move object to separate files.

Changes since v1:
- use RedChannelCapabilities instead of 2 GArrays.

Frediano Ziglio (5):
  red-channel: Remove unused type definition
  red-channel-client: Make capabilities property write only
  red-channel: Separate RedChannelCapabilities
  red-channel-capabilities: Enhance
  red-channel: Use RedChannelCapabilities directly to pass capabilities

 server/Makefile.am|  2 +
 server/cursor-channel-client.c| 22 +--
 server/cursor-channel-client.h|  4 +-
 server/cursor-channel.c   |  6 +--
 server/cursor-channel.h   |  9 ++---
 server/dcc.c  | 22 +--
 server/dcc.h  | 16 +++-
 server/inputs-channel-client.c| 23 +--
 server/inputs-channel-client.h|  5 +--
 server/inputs-channel.c   |  7 +---
 server/main-channel-client.c  | 22 +--
 server/main-channel-client.h  |  3 +-
 server/main-channel.c |  7 +---
 server/main-channel.h |  4 +-
 server/red-channel-capabilities.c | 77 +
 server/red-channel-capabilities.h | 50 
 server/red-channel-client.c   | 80 ---
 server/red-channel-client.h   |  3 +-
 server/red-channel.c  | 20 +++---
 server/red-channel.h  | 15 ++--
 server/red-qxl.c  | 24 +++-
 server/red-qxl.h  | 10 +
 server/red-worker.c   | 11 ++
 server/reds.c | 37 --
 server/smartcard-channel-client.c | 22 +--
 server/smartcard-channel-client.h |  3 +-
 server/smartcard.c|  6 +--
 server/sound.c| 37 --
 server/spicevmc.c | 11 +++---
 29 files changed, 228 insertions(+), 330 deletions(-)
 create mode 100644 server/red-channel-capabilities.c
 create mode 100644 server/red-channel-capabilities.h

-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server v3 3/5] red-channel: Separate RedChannelCapabilities

[Frediano Ziglio]

Signed-off-by: Frediano Ziglio 
---
 server/Makefile.am|  2 ++
 server/red-channel-capabilities.c | 22 ++
 server/red-channel-capabilities.h | 36 
 server/red-channel.h  |  8 +---
 4 files changed, 61 insertions(+), 7 deletions(-)
 create mode 100644 server/red-channel-capabilities.c
 create mode 100644 server/red-channel-capabilities.h

diff --git a/server/Makefile.am b/server/Makefile.am
index a043660..49c0822 100644
--- a/server/Makefile.am
+++ b/server/Makefile.am
@@ -101,6 +101,8 @@ libserver_la_SOURCES =  \
red-channel.h   \
red-channel-client.c\
red-channel-client.h\
+   red-channel-capabilities.c  \
+   red-channel-capabilities.h  \
red-client.c\
red-client.h\
red-common.h\
diff --git a/server/red-channel-capabilities.c 
b/server/red-channel-capabilities.c
new file mode 100644
index 000..39bde66
--- /dev/null
+++ b/server/red-channel-capabilities.c
@@ -0,0 +1,22 @@
+/*
+   Copyright (C) 2017 Red Hat, Inc.
+
+   This library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   This library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with this library; if not, see .
+*/
+#ifdef HAVE_CONFIG_H
+#include 
+#endif
+
+#include "red-channel-capabilities.h"
+
diff --git a/server/red-channel-capabilities.h 
b/server/red-channel-capabilities.h
new file mode 100644
index 000..8729134
--- /dev/null
+++ b/server/red-channel-capabilities.h
@@ -0,0 +1,36 @@
+/* -*- Mode: C; c-basic-offset: 4; indent-tabs-mode: nil -*- */
+/*
+   Copyright (C) 2009-2017 Red Hat, Inc.
+
+   This library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   This library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with this library; if not, see .
+*/
+
+#ifndef RED_CHANNEL_CAPABILITIES_H_
+#define RED_CHANNEL_CAPABILITIES_H_
+
+#include 
+#include 
+
+G_BEGIN_DECLS
+
+typedef struct RedChannelCapabilities {
+int num_common_caps;
+uint32_t *common_caps;
+int num_caps;
+uint32_t *caps;
+} RedChannelCapabilities;
+
+G_END_DECLS
+
+#endif
diff --git a/server/red-channel.h b/server/red-channel.h
index 79aee01..6cee35f 100644
--- a/server/red-channel.h
+++ b/server/red-channel.h
@@ -34,6 +34,7 @@
 #include "reds-stream.h"
 #include "stat.h"
 #include "red-pipe-item.h"
+#include "red-channel-capabilities.h"
 
 G_BEGIN_DECLS
 
@@ -135,13 +136,6 @@ struct RedChannelClass
 
 /* Red Channel interface */
 
-typedef struct RedChannelCapabilities {
-int num_common_caps;
-uint32_t *common_caps;
-int num_caps;
-uint32_t *caps;
-} RedChannelCapabilities;
-
 GType red_channel_get_type(void) G_GNUC_CONST;
 
 void red_channel_add_client(RedChannel *channel, RedChannelClient *rcc);
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server v3 5/5] red-channel: Use RedChannelCapabilities directly to pass capabilities

[Frediano Ziglio]

For each channel there are two set of capabilities, one
for the common ones and one for the specific ones.
A single set were almost always passed using 2 arguments,
a number of elements and an array but then before using
these were converted to a GArray.
Use a single structure (already available) to pass all
channel capabilites using a single argument.

Signed-off-by: Frediano Ziglio 
---
 server/cursor-channel-client.c| 22 ++
 server/cursor-channel-client.h|  4 +--
 server/cursor-channel.c   |  6 ++--
 server/cursor-channel.h   |  9 +++---
 server/dcc.c  | 22 ++
 server/dcc.h  | 16 --
 server/inputs-channel-client.c| 23 ++-
 server/inputs-channel-client.h|  5 +---
 server/inputs-channel.c   |  7 ++---
 server/main-channel-client.c  | 22 ++
 server/main-channel-client.h  |  3 +-
 server/main-channel.c |  7 ++---
 server/main-channel.h |  4 +--
 server/red-channel-client.c   | 62 +--
 server/red-channel-client.h   |  3 +-
 server/red-channel.c  | 19 
 server/red-channel.h  |  7 ++---
 server/red-qxl.c  | 24 ---
 server/red-qxl.h  | 10 ++-
 server/red-worker.c   | 11 +++
 server/reds.c | 37 +++
 server/smartcard-channel-client.c | 22 ++
 server/smartcard-channel-client.h |  3 +-
 server/smartcard.c|  6 ++--
 server/sound.c| 37 +--
 server/spicevmc.c | 11 ---
 26 files changed, 97 insertions(+), 305 deletions(-)

diff --git a/server/cursor-channel-client.c b/server/cursor-channel-client.c
index 56efd1e..1a05f73 100644
--- a/server/cursor-channel-client.c
+++ b/server/cursor-channel-client.c
@@ -93,21 +93,9 @@ void cursor_channel_client_migrate(RedChannelClient *rcc)
 
 CursorChannelClient* cursor_channel_client_new(CursorChannel *cursor, 
RedClient *client, RedsStream *stream,
int mig_target,
-   uint32_t *common_caps, int 
num_common_caps,
-   uint32_t *caps, int num_caps)
+   RedChannelCapabilities *caps)
 {
 CursorChannelClient *rcc;
-GArray *common_caps_array = NULL, *caps_array = NULL;
-
-if (common_caps) {
-common_caps_array = g_array_sized_new(FALSE, FALSE, sizeof 
(*common_caps),
-  num_common_caps);
-g_array_append_vals(common_caps_array, common_caps, num_common_caps);
-}
-if (caps) {
-caps_array = g_array_sized_new(FALSE, FALSE, sizeof (*caps), num_caps);
-g_array_append_vals(caps_array, caps, num_caps);
-}
 
 rcc = g_initable_new(TYPE_CURSOR_CHANNEL_CLIENT,
  NULL, NULL,
@@ -115,16 +103,10 @@ CursorChannelClient* 
cursor_channel_client_new(CursorChannel *cursor, RedClient
  "client", client,
  "stream", stream,
  "monitor-latency", FALSE,
- "common-caps", common_caps_array,
- "caps", caps_array,
+ "caps", caps,
  NULL);
 
common_graphics_channel_set_during_target_migrate(COMMON_GRAPHICS_CHANNEL(cursor),
 mig_target);
 
-if (caps_array)
-g_array_unref(caps_array);
-if (common_caps_array)
-g_array_unref(common_caps_array);
-
 return rcc;
 }
 
diff --git a/server/cursor-channel-client.h b/server/cursor-channel-client.h
index d1dd31d..e2aa3a8 100644
--- a/server/cursor-channel-client.h
+++ b/server/cursor-channel-client.h
@@ -63,9 +63,7 @@ CursorChannelClient* cursor_channel_client_new(CursorChannel 
*cursor,
RedClient *client,
RedsStream *stream,
int mig_target,
-   uint32_t *common_caps,
-   int num_common_caps,
-   uint32_t *caps, int num_caps);
+   RedChannelCapabilities *caps);
 
 void cursor_channel_client_reset_cursor_cache(RedChannelClient *rcc);
 void cursor_channel_client_on_disconnect(RedChannelClient *rcc);
diff --git a/server/cursor-channel.c b/server/cursor-channel.c
index 4fe3f8d..5b23a16 100644
--- a/server/cursor-channel.c
+++ b/server/cursor-channel.c
@@ -406,8 +406,7 @@ void cursor_channel_set_mouse_mode(CursorChannel *cursor, 
uint32_t mode)
 
 void cursor_channel_connect(CursorChannel *cursor, RedClient *client, 
RedsStream *stream,
 

[Spice-devel] [PATCH spice-server v3 4/5] red-channel-capabilities: Enhance

[Frediano Ziglio]

Add function to initialize and destroy this type.
Add GObject type for boxing it.
These changes a in preparation for next patch.

Signed-off-by: Frediano Ziglio 
---
 server/red-channel-capabilities.c | 55 +++
 server/red-channel-capabilities.h | 16 +++-
 2 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/server/red-channel-capabilities.c 
b/server/red-channel-capabilities.c
index 39bde66..dc28298 100644
--- a/server/red-channel-capabilities.c
+++ b/server/red-channel-capabilities.c
@@ -18,5 +18,60 @@
 #include 
 #endif
 
+#include 
+#include 
+#include 
+
 #include "red-channel-capabilities.h"
 
+GType red_channel_capabilities_type;
+
+void red_channel_capabilities_init(RedChannelCapabilities *dest,
+   const RedChannelCapabilities *caps)
+{
+*dest = *caps;
+if (caps->common_caps) {
+dest->common_caps = spice_memdup(caps->common_caps,
+ caps->num_common_caps * 
sizeof(uint32_t));
+}
+if (caps->num_caps) {
+dest->caps = spice_memdup(caps->caps, caps->num_caps * 
sizeof(uint32_t));
+}
+}
+
+void red_channel_capabilities_reset(RedChannelCapabilities *caps)
+{
+if (caps->num_common_caps) {
+free(caps->common_caps);
+}
+
+if (caps->num_caps) {
+free(caps->caps);
+}
+memset(caps, 0, sizeof(*caps));
+}
+
+static RedChannelCapabilities *red_channel_capabilities_dup(const 
RedChannelCapabilities *caps)
+{
+if (!caps) {
+return NULL;
+}
+
+RedChannelCapabilities *res = spice_new(RedChannelCapabilities, 1);
+red_channel_capabilities_init(res, caps);
+return res;
+}
+
+static void red_channel_capabilities_free(RedChannelCapabilities *caps)
+{
+red_channel_capabilities_reset(caps);
+free(caps);
+}
+
+SPICE_CONSTRUCTOR_FUNC(red_channel_capabilities_construct)
+{
+red_channel_capabilities_type =
+g_boxed_type_register_static("red_channel_capabilities_type",
+ (GBoxedCopyFunc) 
red_channel_capabilities_dup,
+ (GBoxedFreeFunc) 
red_channel_capabilities_free);
+}
diff --git a/server/red-channel-capabilities.h 
b/server/red-channel-capabilities.h
index 8729134..1f52cd4 100644
--- a/server/red-channel-capabilities.h
+++ b/server/red-channel-capabilities.h
@@ -20,10 +20,13 @@
 #define RED_CHANNEL_CAPABILITIES_H_
 
 #include 
-#include 
+#include 
 
 G_BEGIN_DECLS
 
+/* Holds channel capabilities.
+ * Channel capabilities are composed by a common part
+ * and a specific one. */
 typedef struct RedChannelCapabilities {
 int num_common_caps;
 uint32_t *common_caps;
@@ -31,6 +34,17 @@ typedef struct RedChannelCapabilities {
 uint32_t *caps;
 } RedChannelCapabilities;
 
+/* Initialize the structure based on a previous one. */
+void red_channel_capabilities_init(RedChannelCapabilities *dest,
+   const RedChannelCapabilities *caps);
+
+/* Reset capabilities.
+ * All resources are freed by this function. */
+void red_channel_capabilities_reset(RedChannelCapabilities *caps);
+
+/* GObject type that can be used to box RedChannelCapabilities */
+extern GType red_channel_capabilities_type;
+
 G_END_DECLS
 
 #endif
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server v3 1/5] red-channel: Remove unused type definition

[Frediano Ziglio]

Signed-off-by: Frediano Ziglio 
---
I don't consider this patch really specific to this set
---
 server/red-channel.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/server/red-channel.c b/server/red-channel.c
index 67a570d..8fe0d33 100644
--- a/server/red-channel.c
+++ b/server/red-channel.c
@@ -594,7 +594,6 @@ int red_channel_no_item_being_sent(RedChannel *channel)
  */
 
 typedef void (*rcc_item_t)(RedChannelClient *rcc, RedPipeItem *item);
-typedef int (*rcc_item_cond_t)(RedChannelClient *rcc, RedPipeItem *item);
 
 /**
  * red_channel_pipes_create_batch:
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-server v3 2/5] red-channel-client: Make capabilities property write only

[Frediano Ziglio]

These properties are not read and code is broken (you would get
uninitialized values).

Signed-off-by: Frediano Ziglio 
---
 server/red-channel-client.c | 20 ++--
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/server/red-channel-client.c b/server/red-channel-client.c
index b583da2..2d2e3fd 100644
--- a/server/red-channel-client.c
+++ b/server/red-channel-client.c
@@ -286,22 +286,6 @@ red_channel_client_get_property(GObject *object,
 case PROP_MONITOR_LATENCY:
 g_value_set_boolean(value, self->priv->monitor_latency);
 break;
-case PROP_COMMON_CAPS:
-{
-GArray *arr = g_array_sized_new(FALSE, FALSE,
-
sizeof(*self->priv->remote_caps.common_caps),
-
self->priv->remote_caps.num_common_caps);
-g_value_take_boxed(value, arr);
-}
-break;
-case PROP_CAPS:
-{
-GArray *arr = g_array_sized_new(FALSE, FALSE,
-
sizeof(*self->priv->remote_caps.caps),
-
self->priv->remote_caps.num_caps);
-g_value_take_boxed(value, arr);
-}
-break;
 default:
 G_OBJECT_WARN_INVALID_PROPERTY_ID(object, property_id, pspec);
 }
@@ -454,7 +438,7 @@ static void 
red_channel_client_class_init(RedChannelClientClass *klass)
   "Common Capabilities",
   G_TYPE_ARRAY,
   G_PARAM_STATIC_STRINGS
-  | G_PARAM_READWRITE
+  | G_PARAM_WRITABLE
   | G_PARAM_CONSTRUCT_ONLY);
 g_object_class_install_property(object_class, PROP_COMMON_CAPS, spec);
 
@@ -462,7 +446,7 @@ static void 
red_channel_client_class_init(RedChannelClientClass *klass)
   "Capabilities",
   G_TYPE_ARRAY,
   G_PARAM_STATIC_STRINGS
-  | G_PARAM_READWRITE
+  | G_PARAM_WRITABLE
   | G_PARAM_CONSTRUCT_ONLY);
 g_object_class_install_property(object_class, PROP_CAPS, spec);
 }
-- 
2.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel