Re: [Spice-devel] [PATCH v6 5/5] Do endian swapping.

[Christophe de Dinechin]

On 23/01/2017 14:53, Michal Suchanek wrote:

This allows running big endian and little endian guest side by side using
cut & paste between them.

There is a general design idea that swapping should come as close to
virtio_read/virtio_write as possible. In particular, the protocol
between vdagent and vdagentd is guest-specific and in native endian.
With muliple layers of headers this is a bit tricky. A few message types
have to be swapped fully before passing through vdagentd.

Signed-off-by: Michal Suchanek 
Signed-off-by: Victor Toso 
---
v2:
  - introduce helper functions to swap (a portion of) a message wholesale
  - pollute fewer places with swapping sometimes at the cost of slightly
more verbose code
v3:
  - use glib byteswap macros in place of endian.h byteswap macros
  - move variable declaration out of case statement
  - reuse more of existing clipboard code
v4:
  - also use glib byteswap for 64bit swaps
  - use file xfer message structure for swapping size
v5:
  - rebase on top of vdagentd: early return on bad message size
---
  src/vdagentd/vdagentd.c| 125 +++--
  src/vdagentd/virtio-port.c |  36 -
  2 files changed, 121 insertions(+), 40 deletions(-)

diff --git a/src/vdagentd/vdagentd.c b/src/vdagentd/vdagentd.c
index 7e16cd2..f8de1e7 100644
--- a/src/vdagentd/vdagentd.c
+++ b/src/vdagentd/vdagentd.c
@@ -78,6 +78,34 @@ static int client_connected = 0;
  static int max_clipboard = -1;
  
  /* utility functions */

+static void virtio_msg_uint32_to_le(uint8_t *_msg, uint32_t size, uint32_t 
offset)
If we are converting uint32 messages, shouln't this take a uint32_t *msg 
as input? See [1] below



+{
+uint32_t i, *msg = (uint32_t *)(_msg + offset);
+
+/* offset - size % 4 should be 0 */

Should this be an assert instead of a comment?

+for (i = 0; i < (size - offset) / 4; i++)
+msg[i] = GUINT32_TO_LE(msg[i]);
+}
+
+static void virtio_msg_uint32_from_le(uint8_t *_msg, uint32_t size, uint32_t 
offset)
+{
+uint32_t i, *msg = (uint32_t *)(_msg + offset);
+
+/* offset - size % 4 should be 0 */
+for (i = 0; i < (size - offset) / 4; i++)
+msg[i] = GUINT32_FROM_LE(msg[i]);
+}
+
+static void virtio_msg_uint16_from_le(uint8_t *_msg, uint32_t size, uint32_t 
offset)
+{
+uint32_t i;
+uint16_t *msg = (uint16_t *)(_msg + offset);
+
+/* offset - size % 2 should be 0 */
+for (i = 0; i < (size - offset) / 2; i++)
+msg[i] = GUINT16_FROM_LE(msg[i]);
+}
+
  /* vdagentd <-> spice-client communication handling */
  static void send_capabilities(struct vdagent_virtio_port *vport,
  uint32_t request)
@@ -102,6 +130,7 @@ static void send_capabilities(struct vdagent_virtio_port 
*vport,
  VD_AGENT_SET_CAPABILITY(caps->caps, VD_AGENT_CAP_GUEST_LINEEND_LF);
  VD_AGENT_SET_CAPABILITY(caps->caps, VD_AGENT_CAP_MAX_CLIPBOARD);
  VD_AGENT_SET_CAPABILITY(caps->caps, VD_AGENT_CAP_AUDIO_VOLUME_SYNC);
+virtio_msg_uint32_to_le((uint8_t *)caps, size, 0);
[1] It looks like having a uint8_t interface even forces us to 
additional casts here.


  
  vdagent_virtio_port_write(vport, VDP_CLIENT_PORT,

VD_AGENT_ANNOUNCE_CAPABILITIES, 0,
@@ -174,8 +203,8 @@ static void do_client_monitors(struct vdagent_virtio_port 
*vport, int port_nr,
  (uint8_t *)mon_config, size);
  
  /* Acknowledge reception of monitors config to spice server / client */

-reply.type  = VD_AGENT_MONITORS_CONFIG;
-reply.error = VD_AGENT_SUCCESS;
+reply.type  = GUINT32_TO_LE(VD_AGENT_MONITORS_CONFIG);
+reply.error = GUINT32_TO_LE(VD_AGENT_SUCCESS);
  vdagent_virtio_port_write(vport, port_nr, VD_AGENT_REPLY, 0,
(uint8_t *), sizeof(reply));
  }
@@ -278,8 +307,8 @@ static void send_file_xfer_status(struct 
vdagent_virtio_port *vport,
const char *msg, uint32_t id, uint32_t 
xfer_status)
  {
  VDAgentFileXferStatusMessage status = {
-.id = id,
-.result = xfer_status,
+.id = GUINT32_TO_LE(id),
+.result = GUINT32_TO_LE(xfer_status),
  };
  syslog(LOG_WARNING, msg, id);
  if (vport)
@@ -361,6 +390,50 @@ static gsize 
vdagent_message_min_size[VD_AGENT_END_MESSAGE] =
  sizeof(VDAgentAudioVolumeSync), /* VD_AGENT_AUDIO_VOLUME_SYNC */
  };
  
+static void vdagent_message_clipboard_from_le(VDAgentMessage *message_header,

+uint8_t *data)
+{
+gsize min_size = vdagent_message_min_size[message_header->type];
+uint32_t *data_type = (uint32_t *) data;
+
+if (VD_AGENT_HAS_CAPABILITY(capabilities, capabilities_size,
+VD_AGENT_CAP_CLIPBOARD_SELECTION)) {
+min_size += 4;

Is that magical 4, or sizeof(something)?

+data_type++;
+}
+
+switch (message_header->type) {
+case VD_AGENT_CLIPBOARD_REQUEST:
+case VD_AGENT_CLIPBOARD:
+   

Re: [Spice-devel] [PATCH v2 spice-gtk 1/2] authentication: Handle failed SASL authentication separately

[Christophe de Dinechin]

> On 21 Feb 2017, at 16:28, Snir Sheriber <ssher...@redhat.com> wrote:
> 
> Hi,
> 
> 
> On 02/20/2017 07:00 PM, Christophe de Dinechin wrote:
>>> On 19 Feb 2017, at 15:47, Snir Sheriber <ssher...@redhat.com> wrote:
>>> 
>>> Remove handling with failures in the SASL authentication
>>> process to separate function
>>> ---
>>> src/spice-channel.c | 44 +++-
>>> 1 file changed, 27 insertions(+), 17 deletions(-)
>>> 
>>> diff --git a/src/spice-channel.c b/src/spice-channel.c
>>> index af67931..cbf1291 100644
>>> --- a/src/spice-channel.c
>>> +++ b/src/spice-channel.c
>>> @@ -1113,28 +1113,38 @@ static int spice_channel_read(SpiceChannel 
>>> *channel, void *data, size_t length)
>>> return length;
>>> }
>>> 
>>> +#if HAVE_SASL
>>> /* coroutine context */
>>> -static void spice_channel_failed_authentication(SpiceChannel *channel,
>>> -gboolean invalidPassword)
>>> +static void spice_channel_failed_sasl_authentication(SpiceChannel *channel)
>>> {
>>> SpiceChannelPrivate *c = channel->priv;
>>> +gint err_code; /* Affects the authentication window activated fileds */
>>> 
>>> if (c->auth_needs_username && c->auth_needs_password)
>>> -g_set_error_literal(>error,
>>> -SPICE_CLIENT_ERROR,
>>> -
>>> SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD_AND_USERNAME,
>>> -_("Authentication failed: password and 
>>> username are required"));
>>> +err_code = SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD_AND_USERNAME;
>>> else if (c->auth_needs_username)
>>> -g_set_error_literal(>error,
>>> -SPICE_CLIENT_ERROR,
>>> -SPICE_CLIENT_ERROR_AUTH_NEEDS_USERNAME,
>>> -_("Authentication failed: username is 
>>> required"));
>>> -else if (c->auth_needs_password)
>>> -g_set_error_literal(>error,
>>> -SPICE_CLIENT_ERROR,
>>> -SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD,
>>> -_("Authentication failed: password is 
>>> required"));
>>> -else if (invalidPassword)
>>> +err_code = SPICE_CLIENT_ERROR_AUTH_NEEDS_USERNAME;
>>> +else
>>> +err_code = SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD;
>>> +
>>> +g_set_error_literal(>error,
>>> +SPICE_CLIENT_ERROR,
>>> +err_code,
>>> +_("SASL authentication failed"));
>> Per the recent discussion (Feb 14 with Christophe F), can’t we map common 
>> SASL errors to Spice messages? To me, it’s different if the problem is that 
>> I used a wrong password or if the server is down. The message as is seems 
>> quite terse.
>> 
>> Errors that seem be reportable (although not all of them seem relevant to 
>> Spice):
>> 
>> SASL_BADAUTH Authentication failure.
>> SASL_NOAUTHZ Authorization failure.
>> SASL_EXPIRED The passphrase expired and must be reset.
>> SASL_DISABLEDAccount disabled.
>> SASL_NOUSER  User not found.
>> SASL_BADVERS Version mismatch with plug-in.
>> SASL_NOVERIFYThe user exists, but there is no verifier for the user.
>> SASL_WEAKPASSThe passphrase is too weak for security policy.
>> SASL_NOUSERPASS  User supplied passwords are not permitted.
>> 
>> 
>> Some that may need to be “translated” in Spicese if they ever get back to us:
>> 
>> SASL_TOOWEAK The mechanism is too weak for this user.
>> SASL_ENCRYPT Encryption is needed to use this mechanism.
>> SASL_TRANS   One time use of a plaintext password will enable 
>> requested mechanism for user.
>> 
>> Others should probably collected into a “default” in a switch statement, 
>> something like “Unexpected SASL error code ”.
>> 
> As link result/error? I guess it would be the best , but first it requires to 
> inform the client in some other way that it can stop waiting for the sasl 
> server start\step result (currently it just freeing the link)
> btw according to sasl docs the full error string should be sent

Yes, but not translated. W

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

[Christophe de Dinechin]

> On 10 Feb 2017, at 14:14, Victor Toso  wrote:
> 
> Hi,
> 
> On Fri, Feb 10, 2017 at 07:51:05AM -0500, Frediano Ziglio wrote:
>>> [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 
>>> ---
>>> server/dcc-private.h |   5 ++
>>> server/dcc.c | 126
>>> +++
>>> server/dcc.h |   1 +
>>> server/display-channel.c |   2 +
>>> server/stream.c  |   5 +-
>>> 5 files changed, 138 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/server/dcc-private.h b/server/dcc-private.h
>>> index 64b32a7..dd54c70 100644
>>> --- a/server/dcc-private.h
>>> +++ b/server/dcc-private.h
>>> @@ -51,6 +51,11 @@ struct DisplayChannelClientPrivate
>>> int num_pixmap_cache_items;
>>> } send_data;
>>> 
>>> +/* Host prefererred video-codec order sorted with client preferred */
>>> +GArray *preferred_video_codecs;
>> 
>> I know this patch is important but every time I arrive here I ask
>> "array of what?" and I close the email.
> 
> Ah :(
> 
>> 
>> C has type[] or type*... GArray is an array of everything you want...
>> I don't like it!
> 
> I used GArray here to keep consistency as we already use GArray for this
> RedVideoCodec struct in other places and this code actually interact
> with it.

GArray and type[] are not identical. GArray is dynamically allocated and can 
grow/shrink. It is closer to calloc/realloc than to type[].

In that case, I think that the number of codecs is fixed within the lifetime of 
the array. However, GArray naturally includes a size (the len field), whereas 
we don’t have the information for a plain array or pointer. So in that specific 
case, as we pass arrays around, even if they have a fixed size, I think GArray 
is the right choice.



> 
> I don't mind moving it to GPtrArray, at least you know that it will be
> an array of pointers.
> 
> Let me know what you think as while I was discussion with Pavel this
> morning, he find out another issue in the patch, which I plan to fix it
> in a followup patch later on.
> 
> PS: You do read the spice code tons of time more then I do, so I might
> not agree but I would do the change for what you think is more legible
> here (unless others disagree, of course)
> 
> Cheers,
>toso
> 
>> 
>> Frediano
>> ___
>> 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 
> 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

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

[Christophe de Dinechin]

> On 9 Feb 2017, at 09:21, Victor Toso  wrote:
> 
> [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 
> ---
> server/dcc-private.h |   5 ++
> server/dcc.c | 126 +++
> server/dcc.h |   1 +
> server/display-channel.c |   2 +
> server/stream.c  |   5 +-
> 5 files changed, 138 insertions(+), 1 deletion(-)
> 
> diff --git a/server/dcc-private.h b/server/dcc-private.h
> index 64b32a7..dd54c70 100644
> --- a/server/dcc-private.h
> +++ b/server/dcc-private.h
> @@ -51,6 +51,11 @@ struct DisplayChannelClientPrivate
> int num_pixmap_cache_items;
> } send_data;
> 
> +/* Host prefererred video-codec order sorted with client preferred */
> +GArray *preferred_video_codecs;
> +/* Last client preferred video-codec order */
> +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 afe37b1..9271ea5 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(>priv->encoders, 
> _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(>priv->preferred_video_codecs, g_array_unref);
> +g_clear_pointer(>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,120 @@ 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)
> +{
> +guint i;
> +const RedVideoCodec *a = a_pointer;
> +const RedVideoCodec *b = b_pointer;
> +GArray *client_pref = user_data;
> +
> +for (i = 0; i < client_pref->len; i++) {
> +if (a->type == g_array_index(client_pref, gint, i))
> +return -1;
> +
> +if (b->type == g_array_index(client_pref, gint, i))
> +return 1;
> +}

The order as you wrote it is not good, because it is possible to have both a < 
b and b < a, e.g. if client_pref[0] matches both a and b, then we will return 
-1 if we pass (a,b) and also -1 if we pass (b, a). That is likely to break the 
sorting algorithm in some subtle cases. My recommendation is something like:

+int client = g_array_index(client_pref, gint, i);
+if (a->type == client && b->type != client))
+return -1;
+
+if (b->type == client && a->type != client)
+return 1;

this will ensure that you get an “equal” and not “less than” result if both a 
and b match.

Alternatively, add a comment explaining why the situation may never arise 
(which I don’t think is true).

> +
> +return 0;
> +}
> +
> +static void dcc_update_preferred_video_codecs(DisplayChannelClient *dcc)
> +{
> +guint i;
> +RedsState *reds;
> +GArray *video_codecs, *server_codecs;
> +GString *msg;
> +
> +reds = 
> red_channel_get_server(red_channel_client_get_channel(>parent));
> +server_codecs = 

Re: [Spice-devel] [PATCH] Don't close all but one display during reboot.

[Christophe de Dinechin]

Is it possible to make the max number of monitors something persistent (e.g. 
set / get that using libvirt), so that the behavior would be consistent between 
a first boot and a reboot?

Christophe

> On 20 Feb 2017, at 15:49, Jonathon Jongsma  wrote:
> 
> On Thu, 2017-02-02 at 10:30 -0600, Jonathon Jongsma wrote:
>> On Thu, 2017-02-02 at 05:29 -0500, Frediano Ziglio wrote:
 
 When a guest is rebooted, the QXL driver gets unloaded at some
 point in
 the reboot process. When the driver is unloaded, the spice server
 sets a
 single flag to FALSE: RedWorker::driver_cap_monitors_config. This
 flag
 indicates whether the driver is capable of sending its own
 monitors
 config
 messages to the client.
 
 The only place this flag is used is when a new primary surface is
 created. If
 this flag is true, the server assumes that the driver will send
 its
 own
 monitors config very soon after the surface is created. If it's
 false, the
 server directly sends its own temporary monitors config message
 to
 the client
 since the driver cannot.  This temporary monitors config message
 is
 based on
 the size of the just-created primary surface and always has a
 maximum monitor
 count of 1.
 
 This flag is initialized to false at startup so that in early
 boot
 (e.g. vga
 text mode), the server will send out these 'temporary' monitor
 config
 messages
 to the client whenever the primary surface is destroyed and re-
 created. This
 causes the client to resize its window to match the size of the
 guest. When
 the
 QXL driver is eventually loaded and starts taking over the
 monitors
 config
 responsibilities, we set this flag to true and the server stops
 sending
 monitors config messages out on its own.
 
 If we reboot and set this flag to false, it will result in the
 server sending
 a
 monitors config message to the client indicating that the guest
 now
 supports
 a
 maximum of 1 monitor. If the guest happens to have more than one
 display
 window
 open, it will destroy those extra windows because they exceed the
 maximum
 allowed number of monitors. This means that if you reboot a guest
 with 4
 monitors, after reboot it will only have 1 monitor.
 
>>> 
>>> After reading this paragraph and the bug I don't see the issue.
>>> I mean, if on my laptop I reboot when I reboot I get a single
>>> monitor
>>> till the OS and other stuff kick in. After a reboot the firmware
>>> use
>>> one monitor or if capable do the mirroring but always the same way.
>>> 
>>> I think the issue is that on first boot the guest activate the
>>> additional monitors and the client do the same while on second
>>> boot (reboot) not so to me looks like more an issue of the client
>>> instead of the server.
>>> 
>> 
>> Well, it could be considered a client issue to some extent, but not
>> an
>> easy one to fix. 
>> 
>>> I would try to get a network capture to look at DisplayChannel
>>> messages if they are more or less the same for first boot and
>>> reboot. If they are the same I would look at the client state
>>> to check that while booting it's the same.
>> 
>> The initial boot and the reboot are the same, and that's basically
>> why
>> the problem exists. At initial boot, it brings up a single display.
>> And
>> on reboot, it also brings up a single display. The issue is that we
>> want the reboot to behave differently.
>> 
>> Initial boot:
>> -
>>  - In early boot, the server sends monitors config message when
>> primary
>> surface is created. monitors=1, max-monitors=1
>>  - client only shows a single window, disables menu items for
>> enabling
>> additional displays because the guest doesn't support more than 1
>>  - When QXL driver is loaded and takes over, it takes over sending
>> monitors config messages. monitors=1, max-monitors=4
>>  - client still shows a single window, but now the menu items for
>> enabling additional menus are enabled
>>  - client enables a second monitor. Client sends monitors-config
>> request to server 
>>  - QXL driver enables the second monitor and sends a new monitors-
>> config response to the client. monitors = 2, max-monitors=4
>> 
>> Reboot:
>> ---
>>  - At some point in the reboot process while the QXL driver is still
>> loaded, it disables all but the first monitor, but still claims to
>> support more than one. monitors=1, max-monitors=4
>>  - client keeps both display windows open, but the second one just
>> says
>> "Waiting for display 2..."
>>  - eventually the QXL driver gets unloaded, and the
>> RedWorker::driver_cap_monitors_config flag gets set to false
>>  - The next time a primary surface is created (during early boot?)
>> the
>> server sends out a new monitors config message to match the size of
>> the
>> primary 

Re: [Spice-devel] [PATCH v2 spice-gtk 1/2] authentication: Handle failed SASL authentication separately

[Christophe de Dinechin]

> On 19 Feb 2017, at 15:47, Snir Sheriber  wrote:
> 
> Remove handling with failures in the SASL authentication
> process to separate function
> ---
> src/spice-channel.c | 44 +++-
> 1 file changed, 27 insertions(+), 17 deletions(-)
> 
> diff --git a/src/spice-channel.c b/src/spice-channel.c
> index af67931..cbf1291 100644
> --- a/src/spice-channel.c
> +++ b/src/spice-channel.c
> @@ -1113,28 +1113,38 @@ static int spice_channel_read(SpiceChannel *channel, 
> void *data, size_t length)
> return length;
> }
> 
> +#if HAVE_SASL
> /* coroutine context */
> -static void spice_channel_failed_authentication(SpiceChannel *channel,
> -gboolean invalidPassword)
> +static void spice_channel_failed_sasl_authentication(SpiceChannel *channel)
> {
> SpiceChannelPrivate *c = channel->priv;
> +gint err_code; /* Affects the authentication window activated fileds */
> 
> if (c->auth_needs_username && c->auth_needs_password)
> -g_set_error_literal(>error,
> -SPICE_CLIENT_ERROR,
> -
> SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD_AND_USERNAME,
> -_("Authentication failed: password and username 
> are required"));
> +err_code = SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD_AND_USERNAME;
> else if (c->auth_needs_username)
> -g_set_error_literal(>error,
> -SPICE_CLIENT_ERROR,
> -SPICE_CLIENT_ERROR_AUTH_NEEDS_USERNAME,
> -_("Authentication failed: username is 
> required"));
> -else if (c->auth_needs_password)
> -g_set_error_literal(>error,
> -SPICE_CLIENT_ERROR,
> -SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD,
> -_("Authentication failed: password is 
> required"));
> -else if (invalidPassword)
> +err_code = SPICE_CLIENT_ERROR_AUTH_NEEDS_USERNAME;
> +else
> +err_code = SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD;
> +
> +g_set_error_literal(>error,
> +SPICE_CLIENT_ERROR,
> +err_code,
> +_("SASL authentication failed"));

Per the recent discussion (Feb 14 with Christophe F), can’t we map common SASL 
errors to Spice messages? To me, it’s different if the problem is that I used a 
wrong password or if the server is down. The message as is seems quite terse.

Errors that seem be reportable (although not all of them seem relevant to 
Spice):

SASL_BADAUTHAuthentication failure.
SASL_NOAUTHZAuthorization failure.
SASL_EXPIREDThe passphrase expired and must be reset.
SASL_DISABLED   Account disabled.
SASL_NOUSER User not found.
SASL_BADVERSVersion mismatch with plug-in.
SASL_NOVERIFY   The user exists, but there is no verifier for the user.
SASL_WEAKPASS   The passphrase is too weak for security policy.
SASL_NOUSERPASS User supplied passwords are not permitted.


Some that may need to be “translated” in Spicese if they ever get back to us:

SASL_TOOWEAKThe mechanism is too weak for this user.
SASL_ENCRYPTEncryption is needed to use this mechanism.
SASL_TRANS  One time use of a plaintext password will enable 
requested mechanism for user.

Others should probably collected into a “default” in a switch statement, 
something like “Unexpected SASL error code ”.


> +
> +c->event = SPICE_CHANNEL_ERROR_AUTH;
> +
> +c->has_error = TRUE; /* force disconnect */
> +}
> +#endif
> +
> +/* coroutine context */
> +static void spice_channel_failed_authentication(SpiceChannel *channel,
> +gboolean invalidPassword)
> +{
> +SpiceChannelPrivate *c = channel->priv;
> +
> +if (invalidPassword)
> g_set_error_literal(>error,
> SPICE_CLIENT_ERROR,
> SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD,
> @@ -1808,7 +1818,7 @@ error:
> if (saslconn)
> sasl_dispose();
> 
> -spice_channel_failed_authentication(channel, FALSE);
> +spice_channel_failed_sasl_authentication(channel);
> ret = FALSE;
> 
> cleanup:
> -- 
> 2.9.3
> 
> ___
> 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 v1] gtk-session: reply agent's clipboard request on failure

[Christophe de Dinechin]

> On 22 Feb 2017, at 13:29, Victor Toso  wrote:
> 
> From: Victor Toso 
> 
> We need to reply back to the agent all clipboard requests even in case
> of failure otherwise it will have a pending request. The following
> error message can be seen in afterwards, when client sends down some
> clipboard data:
> 
>> clipboard: selection requests pending on clipboard ownership
>> change, clearing
> 
> An easy way to reproduce this is:
> 1-) In client, copy image from lo-draw (selection or ctrl+c)

The patch looks good to me, but one thing I don’t understand is why you modify 
a function called “clipboard_received_text_cb” when the description of how to 
reproduce the bug is when you send an image. Is that callback used even for 
non-text data? If so, could we also rename it?


> 2-) In guest, paste it to GEdit (mouse3 our ctrl+v)
> 3-) Move to the client
> 4-) Move back to the guest
> 5-) see error on vdagent logs

Is this the only place where we see the error? Would it be possible to have a 
non-intrusive notification that the paste operation did not work and why?

> 
> The reason for failure is that client's clipboard contains different
> data type (image) then what was requested from guest's editor (text)
> 
> While at it, include extra debug message as it might be hard to
> identify why clipboard did not work.

If it’s hard for you, imagine what it is for Joe MyGrandDadTheLinuxUser ;-)

> 
> Resolves: rhbz#1409854
> Signed-off-by: Victor Toso 
> ---
> src/spice-gtk-session.c | 19 ---
> 1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/src/spice-gtk-session.c b/src/spice-gtk-session.c
> index 0426d8f..315bc26 100644
> --- a/src/spice-gtk-session.c
> +++ b/src/spice-gtk-session.c
> @@ -940,28 +940,33 @@ static void clipboard_received_text_cb(GtkClipboard 
> *clipboard,
>if (self == NULL)
>return;
> 
> +selection = get_selection_from_clipboard(self->priv, clipboard);
> +g_return_if_fail(selection != -1);
> +
>if (text == NULL) {
>SPICE_DEBUG("Failed to retrieve clipboard text");
> -return;
> +goto notify_agent;
>}
> 
>g_return_if_fail(SPICE_IS_GTK_SESSION(self));
> 
> -selection = get_selection_from_clipboard(self->priv, clipboard);
> -g_return_if_fail(selection != -1);
> -
>len = strlen(text);
>if (!check_clipboard_size_limits(self, len)) {
> -return;
> +SPICE_DEBUG("Failed sized limits of clipboard text (%d bytes)", len);
> +len = 0;
> +goto notify_agent;
>}
> 
>/* gtk+ internal utf8 newline is always LF, even on windows */
>conv = fixup_clipboard_text(self, text, );
>if (!check_clipboard_size_limits(self, len)) {
> -g_free(conv);
> -return;
> +SPICE_DEBUG("Failed sized limits of clipboard text (%d bytes)", len);
> +g_clear_pointer(, g_free);
> +len = 0;
> +goto notify_agent;
>}
> 
> +notify_agent:
>spice_main_clipboard_selection_notify(self->priv->main, selection,
>  VD_AGENT_CLIPBOARD_UTF8_TEXT,
>  (guchar *)(conv ?: text), len);
> -- 
> 2.9.3
> 
> ___
> 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] [PATCH spice-gtk] main: Avoid sqrt in monitor compare

[Christophe de Dinechin]

> On 24 Feb 2017, at 13:26, Pavel Grunt  wrote:
> 
> qsort cares about the sign of the difference and that should stay
> the same
> ---
> src/channel-main.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/src/channel-main.c b/src/channel-main.c
> index cd3dee7..50c29f2 100644
> --- a/src/channel-main.c
> +++ b/src/channel-main.c
> @@ -17,7 +17,6 @@
> */
> #include "config.h"
> 
> -#include 
> #include 
> #include 
> #include 
> @@ -1029,8 +1028,8 @@ static int monitors_cmp(const void *p1, const void *p2, 
> gpointer user_data)
> {
>   const VDAgentMonConfig *m1 = p1;
>   const VDAgentMonConfig *m2 = p2;
> -double d1 = sqrt(m1->x * m1->x + m1->y * m1->y);
> -double d2 = sqrt(m2->x * m2->x + m2->y * m2->y);
> +double d1 = m1->x * m1->x + m1->y * m1->y;
> +double d2 = m2->x * m2->x + m2->y * m2->y;

If there really are chances for any of the coordinates to go beyond 16-bit, I 
would write this as:

long m1x = m1->x;
long m1y = m1->y;
long m2x = m2->x;
long m2y = m2->y;
long d1 = m1x * m1x + m1y * m1y;
long d2 = m2x * m2x + m2y * m2y;

The extra cost is zero on x86_64, and it’s giving you the correct result at a 
lower cost than double.

>   int diff = d1 - d2;
> 
>   return diff == 0 ? (char*)p1 - (char*)p2 : diff;

If we only care about the sign of the difference, I would rewrite this as:

return diff != 0 ? diff : (p1 > p2) - (p1 < p2);

The second expression is the sign of the difference between the two pointers, 
but it’s guaranteed to return something good even if you subtract 64-bit 
pointers with 32-bit int, as on x86-64. In that case, with the current code, 
you could be unlucky and have two pointers that are more than 2G apart and get 
a wrong result.

> -- 
> 2.11.1
> 
> ___
> 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] GStreamer's zero-copy code is broken

[Christophe de Dinechin]

> On 24 Feb 2017, at 11:58, Francois Gouget  wrote:
> 
> 
> The patch below breaks the zero-copy code in the GStreamer video 
> encoder:
> 
> commit c3d237075b994fe67e58f2b3164cb579e6f4
> Author: Frediano Ziglio 
> Date:   Mon Dec 12 17:22:50 2016 +
> 
>gstreamer: Avoid memory copy if strides are different
> 
>If bitmap stride and stream stride are different copy was used.
>Using GStreamer 1.0 you can avoid the copy setting correctly
>image offset and stride.
> 
>Signed-off-by: Frediano Ziglio 
>Acked-by: Christophe Fergeau 
> 
> 
> The symptom is that each SpiceBitmap chunk gets incrementally shifted 8 
> pixels to the right. See the attached screenshot. Interestingly the 8 
> extra pixels don't seem to really be random but they don't seem to be 
> identical either.
> 
> Anyway, commenting out the gst_buffer_add_video_meta_full() line fixes 
> it (in cases where there is no need for cropping) but of course is 
> defeats the purpose of the patch.
> 
> I did not see anything obviously wrong in the patch.

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’m not very familiar with that code yet, but that struck me as odd.

> The bug is 
> unrelated to the codec: it happens with mjpeg, vp8 and h264. So to 
> reproduce it simply make sure you're using GStreamer for video, grab 
> big_buck_bunny_480p_h264.mov and play it with either mplayer or totem.
> 
> Maybe it's a gstreamer bug? Here I'm using 1.10.2.
> 
> -- 
> Francois Gouget 
> ___
> 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] [PATCH] Don't close all but one display during reboot.

[Christophe de Dinechin]

Hi Daimon,


In a real system, the connected monitors and their EDID provide information to 
the OS about how many monitors are available, the resolution they support, etc. 
That information is persistent for the OS, i.e. it is still there even when the 
OS is down. Where do you plan to get the “available number of monitors” 
information from in step 2?

My understanding is that we can’t simply use the number of QXL devices, since 
one device can be multihead. Today, there is no persistent configuration of the 
number of monitors that I know of, only a hint regarding the number of channels 
based on the number of QXL instances.

What is the rationale behind the different recommendation for Windows and Linux 
(Windows: 1 QXL device per head; Linux: 1 multi-head QXL device) ?

I think the one case where this approach fails, which Jonathan’s patch tries to 
address, is remote-viewer with multiple monitors configured from remote-viewer. 
Is that correct, or is there another scenario I did not think of?


Thanks
Christophe

> On 23 Feb 2017, at 06:03, Daimon Wang <daimon_sw...@yahoo.com> wrote:
> 
> Hi,
> I'll go against the fix as I don't see any reason for the "assumption".
> 
> Let's split the question into 2 things, max monitor number and which 
> monitor is enabled. 
> The max monitor number seems correct now, controlled by qemu together 
> with qxl. And it's used to control the client menu for monitors.
> The monitor enable should be "remembered" only by the guest OS.while can 
> be controlled by both client and qxl.
> They won't affect each other, and the init-boot/reboot process should be 
> similar:
> 1. (Re)Boot with primary VGA  -- qemu send maxim one monitor with it 
> enabled  -- client have 1 window (or close extra ones)
> 2. Qxl loaded (early in guest boot) -- qxl send maxim n monitor with one 
> enabled  -- client can have 4 window, but only one enabled
> 3. Guest enable some monitors  -- qxl send maxim n monitor with x enabled 
>  --client have corresponding windows enabled (and placed correctly, e.g. 
> onto different monitors)
> 
> Everything looks fine above, but why do we have the bug? The symptom 
> looks as if the guest "forget" to enable the monitor or someone change it. 
> Let's dig it out.
> 
> Regards,
> Daimon
> 
> 
> On Tuesday, February 21, 2017 1:00 AM, Christophe de Dinechin 
> <christo...@dinechin.org> wrote:
> 
> 
> Is it possible to make the max number of monitors something persistent (e.g. 
> set / get that using libvirt), so that the behavior would be consistent 
> between a first boot and a reboot?
> 
> Christophe
> 
>> On 20 Feb 2017, at 15:49, Jonathon Jongsma <jjong...@redhat.com 
>> <mailto:jjong...@redhat.com>> wrote:
>> 
>> On Thu, 2017-02-02 at 10:30 -0600, Jonathon Jongsma wrote:
>>> On Thu, 2017-02-02 at 05:29 -0500, Frediano Ziglio wrote:
>>>>> 
>>>>> When a guest is rebooted, the QXL driver gets unloaded at some
>>>>> point in
>>>>> the reboot process. When the driver is unloaded, the spice server
>>>>> sets a
>>>>> single flag to FALSE: RedWorker::driver_cap_monitors_config. This
>>>>> flag
>>>>> indicates whether the driver is capable of sending its own
>>>>> monitors
>>>>> config
>>>>> messages to the client.
>>>>> 
>>>>> The only place this flag is used is when a new primary surface is
>>>>> created. If
>>>>> this flag is true, the server assumes that the driver will send
>>>>> its
>>>>> own
>>>>> monitors config very soon after the surface is created. If it's
>>>>> false, the
>>>>> server directly sends its own temporary monitors config message
>>>>> to
>>>>> the client
>>>>> since the driver cannot.  This temporary monitors config message
>>>>> is
>>>>> based on
>>>>> the size of the just-created primary surface and always has a
>>>>> maximum monitor
>>>>> count of 1.
>>>>> 
>>>>> This flag is initialized to false at startup so that in early
>>>>> boot
>>>>> (e.g. vga
>>>>> text mode), the server will send out these 'temporary' monitor
>>>>> config
>>>>> messages
>>>>> to the client whenever the primary surface is destroyed and re-
>>>>> created. This
>>>>> causes the client to resize its window to match the size of the
>>>>> guest. When
>

Re: [Spice-devel] Remote 3d support - streaming and lag

[Christophe de Dinechin]

One thing I started to discuss last Wed is how video encoding may also require 
/ introduce a lag on its own. The reason is that some video encodings use 
predictive (P) or bidirectional (B) frames that are relative to surrounding 
frames. Only a small fraction of the frames, the intracoded frames (or 
I-frames, sometimes also called key frames), contain data for the whole 
picture. The P and B frames need neighboring frames to be correctly rendered. 
You can encode practically in any way you want, e.g.  would encode every 
full frame, but IP…PI with 29 P frames would emit only one I frame per second 
at 30FPS. For an overview of predictive encoding, see 
https://en.wikipedia.org/wiki/Video_compression_picture_types. For details 
about predictive encoding in H264, see section 6.4 of 
http://lib.mdp.ac.id/ebook/Karya%20Umum/Video-Compression-Video-Coding-for-Next-generation-Multimedia.pdf
 (but probably way too many details).

Why does it matter in terms of latency? Because while I-frames can be encoded 
on the spot, P frames can only be encoded based on past frames, so you need 
history. B frames are worse, because you need “the future”, so you need to wait 
for future frames to have been emitted before being able to generate a B frame. 
In short, to get a better encoding that uses lower bandwidth, the encoder needs 
more frames, so it ends up introducing latency itself.

In addition, as I understand it, H264 is very flexible with respect to how you 
actually encode the frames. You don’t really encode pictures, you practically 
encode a program that reconstructs the pictures. So there’s a lot of on-going 
effort with respect to how to optimize encoding for this or that scenario. As 
seen from the point of view of a photographer, images that are generated from a 
video game, for example, are “low texture” (i.e. there isn’t much detail over 
large areas) with sharp edges (i.e. you expect sharp lines separating areas, 
and it’s important to preserve the shape of these boundaries). It was hard to 
judge over Blue Jeans, but the perceived quality issues on my side in the demo 
we had last Wed were most likely related to bad preservation of these two 
properties (i.e. we introduced color / luminosity noise in flat areas, whereas 
the shape of edges was visibly affected by compression). These are things that 
would not be half as annoying if you were compressing, say, a picture of waves 
crashing on a beach, or of a landscape with grass and foliage, because we don’t 
have the same expectations with respect to the precise shape of foliage that we 
have for the shape of buildings, streets or cars. But this means we may also 
need heuristic to dynamically adjust encoding based on the kind of input we 
have. Streaming a movie and streaming a 3D game may require different 
parameters if we want the best perceived quality.

Back to latency. I have not re-done the experiment this week, but from memory, 
last time I tried (that was about two years ago), encoding a full-HD screen 
containing “artificial” moving pictures (e.g. a typical Gnome desktop) with 
h264 with an 8-CPU i7 with an acceptable level of quality and an output 
bandwidth compatible with WAN streaming introduced, by itself, at least 100ms 
of latency with relatively low quality, and 500ms if you really wanted an 
output that had no visible artefacts. I may not have perfectly optimized things 
at the time, since I’m not a guru in ffmpeg encoder settings, but that’s how I 
remember it. If you stream to a local desktop, then you can use more bandwidth, 
and getting sub-100ms latency is relatively easy. If you want to try this by 
yourself, instructions are here: http://fomori.org/blog/?p=1213. If you run 
these experiments, please share your findings with various kind of inputs 
(including, obviously, latency and bandwidth).

In short, I don’t doubt that the latency we have been observing is largely a 
result of the simple buffering Frediano mentioned. But I suspect that even if 
we reduced this buffering to practically zero, we would still have at least 
about 100ms of latency just to get good-enough encoding. That’s just a 
suspicion at this point, and further testing and encoder-tuning is required to 
hopefully prove me wrong.


Christophe


> On 9 Feb 2017, at 15:30, Frediano Ziglio  wrote:
> 
> Seems weird to reply to my mail after more than 6 months but apparently
> the content is still worth.
> 
> There is a concept about streaming that people seems to ignore, forget
> or not understand. Why the streaming was added and why it lags!
> 
> If you are at home and if you are watching your Netflix/Amazon prime or
> whatever service you have you want to have good quality and no network
> issues like the movie lagging or showing buffering issues.
> The solution is simple, you increase and monitor the buffer, basically
> you try to have, say, 10 seconds, in the buffer so even if the network
> completely stop working for 8/9 seconds is 

Re: [Spice-devel] [PATCH 1/7] qxl-wddm-dod: Return EDID data to the OS

[Christophe de Dinechin]

> On 12 Feb 2017, at 14:09, Yuri Benditovich  
> wrote:
> 
> Solves failure of HLK "Test for EDID requirements"
> EDID contains capabilities and manufacturer data of
> the emulated display device. Main parameters are:
> Manufacturer code: QXL
> Product ID: 0001
> Working frequency: 75 Hz
> 
> Signed-off-by: Yuri Benditovich 
> ---
> qxldod/QxlDod.cpp | 50 --
> 1 file changed, 48 insertions(+), 2 deletions(-)
> 
> diff --git a/qxldod/QxlDod.cpp b/qxldod/QxlDod.cpp
> index cb64209..35cfb68 100755
> --- a/qxldod/QxlDod.cpp
> +++ b/qxldod/QxlDod.cpp
> @@ -371,6 +371,42 @@ NTSTATUS QxlDod::QueryChildStatus(_Inout_ 
> DXGK_CHILD_STATUS* pChildStatus,
> }
> }
> 
> +static UCHAR edid[256] =
> +{
> +0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, \
> +0x47, 0x0C, 0x01, 0x00, 0x41, 0xFA, 0x38, 0x78, \
> +0xFF, 0x1B, 0x01, 0x04, 0x6A, 0x22, 0x1B, 0x78, \
> +0xEA, 0x32, 0x31, 0xA3, 0x57, 0x4C, 0x9D, 0x25, \
> +0x11, 0x50, 0x54, 0x04, 0x43, 0x00, 0x31, 0x4F, \
> +0x45, 0x4F, 0x61, 0x4F, 0x81, 0x4F, 0x01, 0x01, \
> +0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0xBA, 0x2C, \
> +0x00, 0xA0, 0x50, 0x00, 0x25, 0x40, 0x30, 0x20, \
> +0x37, 0x00, 0x80, 0x00, 0x10, 0x00, 0x00, 0x1E, \
> +0x00, 0x00, 0x00, 0xFD, 0x00, 0x38, 0x50, 0x1E, \
> +0x53, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0xFC, 0x00, 0x51, \
> +0x58, 0x4C, 0x30, 0x30, 0x30, 0x31, 0x0A, 0x20, \
> +0x20, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xFC, \
> +0x00, 0x51, 0x58, 0x4C, 0x30, 0x30, 0x30, 0x31, \
> +0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x01, 0x6E, \
> +0x02, 0x03, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF7, \
> +};
> +

Is there a way to explain what these numbers mean, e.g. a comment with a copy 
of the output of edit-decode?

Christophe

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

Re: [Spice-devel] [PATCH 0/5] Documentation and cleanup of Drawable Tree

[Christophe de Dinechin]

Overall, I like the patches. But I wonder if it would make sense to switch to a 
doxygen format for large comments like this?

Christophe

> On 9 Feb 2017, at 20:46, Jonathon Jongsma  wrote:
> 
> On Fri, 2017-02-03 at 16:55 -0600, Jonathon Jongsma wrote:
>> Here's a slightly expanded and separated version of the drawable tree
>> documentation patch I sent out earlier. There are a few minor code
>> changes, but
>> otherwise it's mostly a matter of splitting some of the documentation
>> into
>> smaller chunks. The last patch still has a bunch of open questions.
>> 
>> Jonathon Jongsma (5):
>>   Shadow: remove unused 'owner' field
>>   DisplayChannel: add documentation for Ring types
>>   DisplayChannel: start documenting drawable tree
>>   DisplayChannel: use proper function name conventions
>>   DisplayChannel: document exclude_region() functions
>> 
>>  server/display-channel-private.h |   6 +-
>>  server/display-channel.c | 281
>> +--
>>  server/display-channel.h |   6 +
>>  server/tree.c|  13 +-
>>  server/tree.h|   7 +-
>>  5 files changed, 295 insertions(+), 18 deletions(-)
>> 
> 
> Any other takers to give feedback on the remaining patches? (first two
> are merged already)
> 
> Jonathon
> ___
> 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] bool or gboolean

[Christophe de Dinechin]

> On 16 Feb 2017, at 13:17, Pavel Grunt  wrote:
> 
> On Wed, 2017-02-15 at 11:39 -0500, Frediano Ziglio wrote:
>> Hi,
>>   question was raised recently on the ML and IRC.
>> 
>> Some time ago we decided to use gboolean but some of us would like
>> to discuss again.
>> 
>> As any style changes there's no right or wrong, mainly personal
>> opinions but I think consistency is quite important.
>> 
>> Some consideration (feel free to add/remove/comment)
>> - gboolean is more used in the code (about 76%)
>> - TRUE/FALSE are more used (96%)
>> - bool is C99 convention, defined in stdbool.h
>> - using gcc the bool type is a bit different from gboolean
>>   (which basically is an int) catching some problems as
>>   warnings (like cast between different function pointers
>>   using bool instead of gboolean/int)
> this is very important point in my opinion
> 
>> - bool is easier to write (OT: and my vim is more happy too)
>> 
>> There are 2 kind of decision:
>> - prefer bool or gboolean
>> - stay consistent with constants (bool -> true/false,
>>   gboolean -> TRUE/FALSE), continue to use TRUE/FALSE.
>> 
>> I think as usual new code should follow style while old
>> for "blame" purposes should stay as is (unless code stop
>> compiling for instance).
> I agree, no mass rename
> 
>> 
>> For opinions
>> 
>> - bool/gboolean
>>   - bool
>>> +1
> +1
+1
>> 
>>   - gboolean
>> 
>> - consistent with type
>>   - yes
>>> +1 
> +1
+1

>> 
>>   - no
>> 
>> Frediano
>> ___
>> 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

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

Re: [Spice-devel] [spice-server v4 5/5] Change some spice_printerr() to spice_debug()

[Christophe de Dinechin]

> On 15 Feb 2017, at 12:45, Frediano Ziglio  wrote:
> 
>> @@ -134,7 +134,7 @@ static void red_qxl_display_migrate(RedChannelClient
>> *rcc)
>> }
>> g_object_get(channel, "channel-type", , "id", , NULL);
>> dispatcher = (Dispatcher *)g_object_get_data(G_OBJECT(channel),
>> "dispatcher");
>> -spice_printerr("channel type %u id %u", type, id);
>> +spice_debug("channel type %u id %u", type, id);
>> payload.rcc = rcc;
>> dispatcher_send_message(dispatcher,
>> RED_WORKER_MESSAGE_DISPLAY_MIGRATE,
> 
> Looks like there's lot of debugging on migration.
> Like we are not really sure the code is working.

Maybe someone once needed a lot of debug information, and kept it around in 
case things start going south. That probably means we have annotations that may 
end up being annoying for everybody debugging anything else than migration.

This leads me to a meta-question: would it make sense to add “traces” to the 
spice code, i.e. dynamically configurable flags that activate sets of related 
printf. Today, we have spice “errors”, “debug” or “info”, but we could have 
finer-grained logging for specific topics, e.g. migration or encoding.

In Tao3D, there are topical traces like this declared here: 
https://github.com/c3d/tao-3D/blob/master/tao/traces.tbl. If you want to have 
the “font” trace activated, you simply run the program with the -tfont option, 
or set a flag from within a debugger. Within the code, traces are tested with 
something like if (TRACE(font)), e.g. 
https://github.com/c3d/tao-3D/blob/master/tao/font.cpp#L102. A special form a 
printf takes a trace name as input, e.g. we could have spice_trace(font, …). 
The cost of a not-taken trace is a mere not-taken if statement with a bit-field 
read (one trace = one bit), so the overhead is really low. This means that you 
can leave verbose debug information in place in case it helps addressing a 
specific kind of debug situation.

Would anything like this make sense for spice?


>> @@ -148,7 +148,7 @@ static void red_qxl_set_cursor_peer(RedChannel *channel,
>> RedClient *client, Reds
>> {
>> RedWorkerMessageCursorConnect payload = {0,};
>> Dispatcher *dispatcher = (Dispatcher
>> *)g_object_get_data(G_OBJECT(channel), "dispatcher");
>> -spice_printerr("");
>> +spice_debug("");
>> payload.client = client;
>> payload.stream = stream;
>> payload.migration = migration;
> 
> Remove
> 
>> @@ -176,7 +176,7 @@ static void
>> red_qxl_disconnect_cursor_peer(RedChannelClient *rcc)
>> }
>> 
>> dispatcher = (Dispatcher *)g_object_get_data(G_OBJECT(channel),
>> "dispatcher");
>> -spice_printerr("");
>> +spice_debug("");
>> payload.rcc = rcc;
>> 
>> dispatcher_send_message(dispatcher,
> 
> Remove
> 
>> @@ -196,7 +196,7 @@ static void red_qxl_cursor_migrate(RedChannelClient *rcc)
>> }
>> g_object_get(channel, "channel-type", , "id", , NULL);
>> dispatcher = (Dispatcher *)g_object_get_data(G_OBJECT(channel),
>> "dispatcher");
>> -spice_printerr("channel type %u id %u", type, id);
>> +spice_debug("channel type %u id %u", type, id);
>> payload.rcc = rcc;
>> dispatcher_send_message(dispatcher,
>> RED_WORKER_MESSAGE_CURSOR_MIGRATE,
>> @@ -652,7 +652,7 @@ static void red_qxl_loadvm_commands(QXLState *qxl_state,
>> {
>> RedWorkerMessageLoadvmCommands payload;
>> 
>> -spice_printerr("");
>> +spice_debug("");
>> payload.count = count;
>> payload.ext = ext;
>> dispatcher_send_message(qxl_state->dispatcher,
>> diff --git a/server/smartcard.c b/server/smartcard.c
>> index a7cc614..4d27eff 100644
>> --- a/server/smartcard.c
>> +++ b/server/smartcard.c
>> @@ -213,7 +213,7 @@ static void smartcard_remove_client(RedCharDevice *self,
>> RedClient *client)
>> RedCharDeviceSmartcard *dev = RED_CHAR_DEVICE_SMARTCARD(self);
>> RedChannelClient *rcc = RED_CHANNEL_CLIENT(dev->priv->scc);
>> 
>> -spice_printerr("smartcard  dev %p, client %p", dev, client);
>> +spice_debug("smartcard  dev %p, client %p", dev, client);
>> spice_assert(dev->priv->scc &&
>>  red_channel_client_get_client(rcc) == client);
>> red_channel_client_shutdown(rcc);
> 
> Not sure. Not really into smartcard to have an opinion.
> 
>> diff --git a/server/spicevmc.c b/server/spicevmc.c
>> index 4c9f442..2b3290a 100644
>> --- a/server/spicevmc.c
>> +++ b/server/spicevmc.c
>> @@ -436,7 +436,7 @@ static void spicevmc_char_dev_remove_client(RedCharDevice
>> *self,
>> RedCharDeviceSpiceVmc *vmc = RED_CHAR_DEVICE_SPICEVMC(self);
>> RedVmcChannel *channel = RED_VMC_CHANNEL(vmc->channel);
>> 
>> -spice_printerr("vmc channel %p, client %p", channel, client);
>> +spice_debug("vmc channel %p, client %p", channel, client);
>> spice_assert(channel->rcc &&
>>  red_channel_client_get_client(channel->rcc) == client);
>> 
> 
> Same as smartcard
> 
> 

[Spice-devel] [PATCH] Remove X == TRUE tests for non-boolean values

[Christophe de Dinechin]

Using X == TRUE is fragile, since the input value is a uint8_t. It would be
surprising if the value was set to 2 or 0xFF and the test failed.

Signed-off-by: Christophe de Dinechin <dinec...@redhat.com>
---
 server/dcc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/server/dcc.c b/server/dcc.c
index afe37b1..7cfa72b 100644
--- a/server/dcc.c
+++ b/server/dcc.c
@@ -398,7 +398,7 @@ static void 
add_drawable_surface_images(DisplayChannelClient *dcc, Drawable *dra
 
 surface_id = drawable->surface_deps[x];
 if (surface_id != -1) {
-if (dcc->priv->surface_client_created[surface_id] == TRUE) {
+if (dcc->priv->surface_client_created[surface_id]) {
 continue;
 }
 dcc_create_surface(dcc, surface_id);
@@ -407,7 +407,7 @@ static void 
add_drawable_surface_images(DisplayChannelClient *dcc, Drawable *dra
 }
 }
 
-if (dcc->priv->surface_client_created[drawable->surface_id] == TRUE) {
+if (dcc->priv->surface_client_created[drawable->surface_id]) {
 return;
 }
 
-- 
2.10.1 (Apple Git-78)

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

Re: [Spice-devel] Multi-head Spice

[Christophe de Dinechin]

> On 28 Feb 2017, at 08:58, Christophe Fergeau <cferg...@redhat.com> wrote:
> 
> On Mon, Feb 27, 2017 at 04:18:12PM -0600, Jonathon Jongsma wrote:
>> On Mon, 2017-02-27 at 17:53 +0100, Christophe de Dinechin wrote:
>>> I tried to setup a multi-head guest, but I’m having trouble getting
>>> multiple displays to work correctly
>>> 
>>> For Jonathon, the part that I had trouble with was adding “heads =
>>> ‘4’" to the video / QXL configuration. I don’t see it documented in
>>> https://www.spice-space.org/spice-user- 
>>> <https://www.spice-space.org/spice-user->
>>> manual.html#_multiple_monitor_support.
>> 
>> Yep, it's a fairly new feature. I'm working on additional multi-monitor 
>> documentation and will be sure to include that.
> 
> Yep, we totally missed it when 'heads' support was added :( virt-manager
> UI needs to be able to set this too..
> 
Ah, that was my next question ;-)


>> 
>>> 
>>> For Christophe F, what I get with the configuration file http://paste
>>> bin.com/FEXbjaE3 is shown in the following picture https://redskincat
>>> .wordpress.com/2017/02/27/learning-more-about-mesa/#jp-carousel-1224.
>>> As far as I remember, this is pretty much a default configuration of
>>> Fedora 25 after install from the live CD. If I understand correctly,
>>> the difference with you is that I actually installed.
>>> 
>>> Does anybody else see this? If not, what could be wrong with my
>>> setup?
>>> 
>> 
>> I don't see anything obviously wrong with the configuration. If you
>> close the spice client and immediately re-connect does it still show
>> the same thing in both windows?
>> 
>> Can you capture the debug output of running virt-viewer with the --
>> debug and --spice-debug options while you enable the second monitor?
>> That might give a clue about what's happening.
> 
> Also, what window manager are you using on the client? The window
> decorations don't look like default GNOME setup? The linux client is
> running on bare-metal, not in an osx VM?

This is Cinnamon. The Linux client is running on the same Fedora 25 host.

So I thought I’d test with Gnome. It did not let me log-in. Tried with Gnome on 
Xorg. Same. Could not log in in Cinnamon anymore either… So I rebooted. And my 
machine landed in the emergency shell. My journalctl log is full of btrfs 
errors. The machine seems pretty sad.

Of note, this was my “stable” Linux machine so far, the only one that did not 
have some flaky component… I have three hosts (four if you include the Mac), 
they all have something wrong:

- The “Shuttle” machine is unstable, always have been. I hoped it would improve 
by swapping RAM or graphic card, but did not.

- The “Big” machine has new “bad sectors” on the boot hard disk daily. I have 
bought a new disk, did not have time to install it yet.

- The “Muse” machine I was using here was the most stable one, if the oldest. 
So far, it had performed flawlessly. Grrr.

If I can bring Muse back up, I’ll tell you if the result is different on Gnome. 
Meanwhile, I’ll try the heads=4 setup on a new VM on Big (which is Gnome by 
default)


Christophe


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

Re: [Spice-devel] Multi-head Spice

[Christophe de Dinechin]

> On 28 Feb 2017, at 10:15, Pavel Grunt <pgr...@redhat.com> wrote:
> 
> Hi,
> 
> On Tue, 2017-02-28 at 11:01 +0200, Snir Sheriber wrote:
>> Hi,
>> 
>> On 02/28/2017 09:58 AM, Christophe Fergeau wrote:
>>> On Mon, Feb 27, 2017 at 04:18:12PM -0600, Jonathon Jongsma wrote:
>>>> On Mon, 2017-02-27 at 17:53 +0100, Christophe de Dinechin wrote:
>>>>> I tried to setup a multi-head guest, but I’m having trouble
>>>>> getting
>>>>> multiple displays to work correctly
>>>>> 
>>>>> For Jonathon, the part that I had trouble with was adding
>>>>> “heads =
>>>>> ‘4’" to the video / QXL configuration. I don’t see it
>>>>> documented in
>>>>> https://www.spice-space.org/spice-user-
>>>>> manual.html#_multiple_monitor_support.
>>>> 
>>>> Yep, it's a fairly new feature. I'm working on additional multi-
>>>> monitor 
>>>> documentation and will be sure to include that.
>>> 
>>> Yep, we totally missed it when 'heads' support was added :( virt-
>>> manager
>>> UI needs to be able to set this too..
>>> 
>>>>> For Christophe F, what I get with the configuration file http:
>>>>> //paste
>>>>> bin.com/FEXbjaE3 is shown in the following picture https://red
>>>>> skincat
>>>>> .wordpress.com/2017/02/27/learning-more-about-mesa/#jp-
>>>>> carousel-1224.
>>>>> As far as I remember, this is pretty much a default
>>>>> configuration of
>>>>> Fedora 25 after install from the live CD. If I understand
>>>>> correctly,
>>>>> the difference with you is that I actually installed.
>>>>> 
>>>>> Does anybody else see this? If not, what could be wrong with
>>>>> my
>>>>> setup?
>>>>> 
>>>> 
>>>> I don't see anything obviously wrong with the configuration. If
>>>> you
>>>> close the spice client and immediately re-connect does it still
>>>> show
>>>> the same thing in both windows?
>>>> 
>>>> Can you capture the debug output of running virt-viewer with the
>>>> --
>>>> debug and --spice-debug options while you enable the second
>>>> monitor?
>>>> That might give a clue about what's happening.
>>> 
>>> Also, what window manager are you using on the client? The window
>>> decorations don't look like default GNOME setup? The linux client
>>> is
>>> running on bare-metal, not in an osx VM?
>>> 
>>> Christophe
>>> 
>>  
>> I'm having similar issue here (fed 25 guest), and even worse :/,
>> when
>> i set up the 2 displays as primary and secondary it starts by
>> showing both
>> displays as secondary (2) but when i move the mouse towards the
>> menu both are becoming primary (1) , and it keeps jumping between
>> 1<->2
>> 
>> I tried both x11 and wayland on the fedora 25 guest - same issue,
>> but works
>> well with fedora 24 guest
>> 
>> http://pastebin.test.redhat.com/459770
> 
> per:
> (remote-viewer:13074): GSpice-DEBUG: channel-display.c:1726 display-
> 2:0: received new monitors config from guest: n: 2/4
> (remote-viewer:13074): GSpice-DEBUG: channel-display.c:1746 display-
> 2:0: monitor id: 0, surface id: 0, +0+0-1024x768
> (remote-viewer:13074): GSpice-DEBUG: channel-display.c:1746 display-
> 2:0: monitor id: 1, surface id: 0, +0+0-1024x740
> 
> the guest requests to "mirror". Does it have enough memory for qxl? Do
> you have `virsh dumpxml` ?

This was in my initial mail, http://pastebin.com/FEXbjaE3 
<http://pastebin.com/FEXbjaE3> 

Christophe

> 
> Pavel
> 
>> 
>> Snir.
>> 
>>> ___
>>> 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
> ___
> 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] Multi-head Spice

[Christophe de Dinechin]

> On 28 Feb 2017, at 10:01, Snir Sheriber <ssher...@redhat.com> wrote:
> 
> Hi,
> 
> On 02/28/2017 09:58 AM, Christophe Fergeau wrote:
>> On Mon, Feb 27, 2017 at 04:18:12PM -0600, Jonathon Jongsma wrote:
>>> On Mon, 2017-02-27 at 17:53 +0100, Christophe de Dinechin wrote:
>>>> I tried to setup a multi-head guest, but I’m having trouble getting
>>>> multiple displays to work correctly
>>>> 
>>>> For Jonathon, the part that I had trouble with was adding “heads =
>>>> ‘4’" to the video / QXL configuration. I don’t see it documented in
>>>> https://www.spice-space.org/spice-user 
>>>> <https://www.spice-space.org/spice-user>-
>>>> manual.html#_multiple_monitor_support.
>>> Yep, it's a fairly new feature. I'm working on additional multi-monitor 
>>> documentation and will be sure to include that.
>> Yep, we totally missed it when 'heads' support was added :( virt-manager
>> UI needs to be able to set this too..
>> 
>>>> For Christophe F, what I get with the configuration file http://paste 
>>>> <http://paste/>
>>>> bin.com/FEXbjaE3 is shown in the following picture https://redskincat 
>>>> <https://redskincat/>
>>>> .wordpress.com/2017/02/27/learning-more-about-mesa/#jp-carousel-1224.
>>>> As far as I remember, this is pretty much a default configuration of
>>>> Fedora 25 after install from the live CD. If I understand correctly,
>>>> the difference with you is that I actually installed.
>>>> 
>>>> Does anybody else see this? If not, what could be wrong with my
>>>> setup?
>>>> 
>>> I don't see anything obviously wrong with the configuration. If you
>>> close the spice client and immediately re-connect does it still show
>>> the same thing in both windows?
>>> 
>>> Can you capture the debug output of running virt-viewer with the --
>>> debug and --spice-debug options while you enable the second monitor?
>>> That might give a clue about what's happening.
>> Also, what window manager are you using on the client? The window
>> decorations don't look like default GNOME setup? The linux client is
>> running on bare-metal, not in an osx VM?
>> 
>> Christophe
>> 
> 
> I'm having similar issue here (fed 25 guest), and even worse :/,

Good to know I’m not hallucinating or heisenbugging ;-)

> when
> i set up the 2 displays as primary and secondary it starts by showing both
> displays as secondary (2) but when i move the mouse towards the
> menu both are becoming primary (1) , and it keeps jumping between 1<->2

Towards which menu? I don’t think I have tried this operation. If I can bring 
Muse back up, I can try this.

> 
> I tried both x11 and wayland on the fedora 25 guest - same issue, but works
> well with fedora 24 guest

So this would be a problem with QXL more than with virt-viewer?

Christophe

> 
> http://pastebin.test.redhat.com/459770 
> <http://pastebin.test.redhat.com/459770>
> 
> Snir.
> 
>> 
>> ___
>> Spice-devel mailing list
>> Spice-devel@lists.freedesktop.org <mailto:Spice-devel@lists.freedesktop.org>
>> https://lists.freedesktop.org/mailman/listinfo/spice-devel 
>> <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

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

Re: [Spice-devel] Multi-head Spice

[Christophe de Dinechin]

> On 27 Feb 2017, at 23:18, Jonathon Jongsma <jjong...@redhat.com> wrote:
> 
> On Mon, 2017-02-27 at 17:53 +0100, Christophe de Dinechin wrote:
>> I tried to setup a multi-head guest, but I’m having trouble getting
>> multiple displays to work correctly
>> 
>> For Jonathon, the part that I had trouble with was adding “heads =
>> ‘4’" to the video / QXL configuration. I don’t see it documented in
>> https://www.spice-space.org/spice-user-
>> manual.html#_multiple_monitor_support.
> 
> Yep, it's a fairly new feature. I'm working on additional multi-monitor 
> documentation and will be sure to include that.

Thanks

> 
>> 
>> For Christophe F, what I get with the configuration file http://paste
>> bin.com/FEXbjaE3 is shown in the following picture https://redskincat
>> .wordpress.com/2017/02/27/learning-more-about-mesa/#jp-carousel-1224.
>> As far as I remember, this is pretty much a default configuration of
>> Fedora 25 after install from the live CD. If I understand correctly,
>> the difference with you is that I actually installed.
>> 
>> Does anybody else see this? If not, what could be wrong with my
>> setup?
>> 
> 
> I don't see anything obviously wrong with the configuration. If you
> close the spice client and immediately re-connect does it still show
> the same thing in both windows?

Yes. It reopens two windows, both with monitor 2.


> 
> Can you capture the debug output of running virt-viewer with the --
> debug and --spice-debug options while you enable the second monitor?
> That might give a clue about what's happening.

Attached. I find it suspicious that we only have surface id 0.

(virt-viewer:16396): GSpice-DEBUG: channel-display.c:1746 display-2:0: monitor 
id: 0, surface id: 0, +0+0-1152x768

There’s also this message:

(virt-viewer:16396): GSpice-DEBUG: channel-main.c:1492 Not sending monitors 
config, at least one monitor must have dimensions


Thanks
Christophe


> 
> Thanks,
> Jonathon

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

Re: [Spice-devel] [PATCH] Remove X == TRUE tests for non-boolean values

[Christophe de Dinechin]

> On 27 Feb 2017, at 13:12, Christophe Fergeau <cferg...@redhat.com> wrote:
> 
> On Mon, Feb 27, 2017 at 06:58:47AM -0500, Frediano Ziglio wrote:
>>> 
>>> Using X == TRUE is fragile, since the input value is a uint8_t. It would be
>>> surprising if the value was set to 2 or 0xFF and the test failed.
>>> 
>>> Signed-off-by: Christophe de Dinechin <dinec...@redhat.com 
>>> <mailto:dinec...@redhat.com>>
>> 
>> Acked-by: Frediano Ziglio <fzig...@redhat.com <mailto:fzig...@redhat.com>>
> 
> This apparently is going to cause warnings with gcc 7, see
> https://www.redhat.com/archives/libvir-list/2017-February/msg01199.html 
> <https://www.redhat.com/archives/libvir-list/2017-February/msg01199.html>
> 
> if (dcc->priv->surface_client_created[surface_id] != 0) {} should work,
> or
> diff --git a/server/dcc-private.h b/server/dcc-private.h
> index 64b32a7..1cf3b0d 100644
> --- a/server/dcc-private.h
> +++ b/server/dcc-private.h
> @@ -51,7 +51,7 @@ struct DisplayChannelClientPrivate
> int num_pixmap_cache_items;
> } send_data;
> 
> -uint8_t surface_client_created[NUM_SURFACES];
> +bool surface_client_created[NUM_SURFACES];
> QRegion surface_client_lossy_region[NUM_SURFACES];
> 
> StreamAgent stream_agents[NUM_STREAMS];
> 
> which seems to be a more accurate type for 'surface_client_created’.

Looking at the declaration, I just noticed we pre-allocate 1 surfaces. Why 
is this not dynamic allocation? Is it sane to allocate 250K statically with 
each DisplayChannelClientPrivate?

I’m tempted to replace this with a dynamic array of QRegion *, where a non-NULL 
pointer indicates that the client has been created. OK with that? I expect some 
operations will be faster because they won’t iterate over 1 mostly empty 
surfaces. There will be one extra indirection when accessing the 
surface_client_lossy region, but x86_64 became pretty darn good at chasing 
pointers like that thanks to C++ vtables ;-)


Christophe
> 
> Chistophe
> 
> 
> 
>> 
>>> ---
>>> server/dcc.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/server/dcc.c b/server/dcc.c
>>> index afe37b1..7cfa72b 100644
>>> --- a/server/dcc.c
>>> +++ b/server/dcc.c
>>> @@ -398,7 +398,7 @@ static void
>>> add_drawable_surface_images(DisplayChannelClient *dcc, Drawable *dra
>>> 
>>> surface_id = drawable->surface_deps[x];
>>> if (surface_id != -1) {
>>> -if (dcc->priv->surface_client_created[surface_id] == TRUE) {
>>> +if (dcc->priv->surface_client_created[surface_id]) {
>>> continue;
>>> }
>>> dcc_create_surface(dcc, surface_id);
>>> @@ -407,7 +407,7 @@ static void
>>> add_drawable_surface_images(DisplayChannelClient *dcc, Drawable *dra
>>> }
>>> }
>>> 
>>> -if (dcc->priv->surface_client_created[drawable->surface_id] == TRUE) {
>>> +if (dcc->priv->surface_client_created[drawable->surface_id]) {
>>> return;
>>> }
>>> 
>> 
>> Frediano
>> ___
>> Spice-devel mailing list
>> Spice-devel@lists.freedesktop.org <mailto:Spice-devel@lists.freedesktop.org>
>> https://lists.freedesktop.org/mailman/listinfo/spice-devel 
>> <https://lists.freedesktop.org/mailman/listinfo/spice-devel>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org <mailto:Spice-devel@lists.freedesktop.org>
> https://lists.freedesktop.org/mailman/listinfo/spice-devel 
> <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] [PATCH] Remove X == TRUE tests for non-boolean values

[Christophe de Dinechin]

> On 27 Feb 2017, at 17:10, Frediano Ziglio <fzig...@redhat.com> wrote:
> 
> On 27 Feb 2017, at 13:12, Christophe Fergeau <cferg...@redhat.com 
> <mailto:cferg...@redhat.com>> wrote:
> 
> On Mon, Feb 27, 2017 at 06:58:47AM -0500, Frediano Ziglio wrote:
> 
> Using X == TRUE is fragile, since the input value is a uint8_t. It would be
> surprising if the value was set to 2 or 0xFF and the test failed.
> 
> Signed-off-by: Christophe de Dinechin <dinec...@redhat.com 
> <mailto:dinec...@redhat.com>>
> 
> Acked-by: Frediano Ziglio <fzig...@redhat.com <mailto:fzig...@redhat.com>>
> 
> This apparently is going to cause warnings with gcc 7, see
> https://www.redhat.com/archives/libvir-list/2017-February/msg01199.html 
> <https://www.redhat.com/archives/libvir-list/2017-February/msg01199.html>
> 
> if (dcc->priv->surface_client_created[surface_id] != 0) {} should work,
> or
> diff --git a/server/dcc-private.h b/server/dcc-private.h
> index 64b32a7..1cf3b0d 100644
> --- a/server/dcc-private.h
> +++ b/server/dcc-private.h
> @@ -51,7 +51,7 @@ struct DisplayChannelClientPrivate
> int num_pixmap_cache_items;
> } send_data;
> 
> -uint8_t surface_client_created[NUM_SURFACES];
> +bool surface_client_created[NUM_SURFACES];
> QRegion surface_client_lossy_region[NUM_SURFACES];
> 
> StreamAgent stream_agents[NUM_STREAMS];
> 
> which seems to be a more accurate type for 'surface_client_created’.
> 
> Looking at the declaration, I just noticed we pre-allocate 1 surfaces. 
> Why is this not dynamic allocation? Is it sane to allocate 250K statically 
> with each DisplayChannelClientPrivate?
> I think mostly old style pool allocations. Considering that usually we use 
> only 1 surface would be indeed much smaller.
> 
> I’m tempted to replace this with a dynamic array of QRegion *, where a 
> non-NULL pointer indicates that the client has been created. OK with that? I 
> expect some operations will be faster because they won’t iterate 
> I would use a new structure like
> 
> typedef struct {
> QRegion region;
> } RedClientSurfaceInfo;
> 
> make source code a bit longer (not the binary) but can be easily extended and 
> it's easier to
> understand a dcc->client_surface_info[i] != NULL than a 
> dcc->surface_client_lossy_region[i] != NULL.

Yes. Agreed.

> 
> over 1 mostly empty surfaces. There will be one extra indirection when 
> accessing the surface_client_lossy region, but x86_64 became pretty darn good 
> at chasing pointers like that thanks to C++ vtables ;-)
> Last sentence is a bit cryptic I think :-)

Sorry. Did not mean to be. What I meant is that chasing pointers like a->b->c 
is required to perform well for virtual function calls in C++ (this->foo() 
translates into this->vptr->vtbl[n]()). At some point, it was a huge 
performance hit for many workloads, because CPUs were not that good at 
prefetching this kind of double-dereferences. But C++ and other similar 
programming techniques with double indirection became so prevalent that CPUs 
are now quite good at it.


> Could be true.
> I don't think the extra indirection is a big deal, it's mostly used on 
> surface/channel creation/destroying.

OK

Christophe

> 
> 
> Christophe
> 
> Chistophe
> 
> 
> 
> 
> ---
> server/dcc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/server/dcc.c b/server/dcc.c
> index afe37b1..7cfa72b 100644
> --- a/server/dcc.c
> +++ b/server/dcc.c
> @@ -398,7 +398,7 @@ static void
> add_drawable_surface_images(DisplayChannelClient *dcc, Drawable *dra
> 
> surface_id = drawable->surface_deps[x];
> if (surface_id != -1) {
> -if (dcc->priv->surface_client_created[surface_id] == TRUE) {
> +if (dcc->priv->surface_client_created[surface_id]) {
> continue;
> }
> dcc_create_surface(dcc, surface_id);
> @@ -407,7 +407,7 @@ static void
> add_drawable_surface_images(DisplayChannelClient *dcc, Drawable *dra
> }
> }
> 
> -if (dcc->priv->surface_client_created[drawable->surface_id] == TRUE) {
> +if (dcc->priv->surface_client_created[drawable->surface_id]) {
> return;
> }
> Frediano

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

[Spice-devel] Multi-head Spice

[Christophe de Dinechin]

I tried to setup a multi-head guest, but I’m having trouble getting multiple 
displays to work correctly

For Jonathon, the part that I had trouble with was adding “heads = ‘4’" to the 
video / QXL configuration. I don’t see it documented in 
https://www.spice-space.org/spice-user-manual.html#_multiple_monitor_support.

For Christophe F, what I get with the configuration file 
http://pastebin.com/FEXbjaE3  is shown in the 
following picture 
https://redskincat.wordpress.com/2017/02/27/learning-more-about-mesa/#jp-carousel-1224
 
.
 As far as I remember, this is pretty much a default configuration of Fedora 25 
after install from the live CD. If I understand correctly, the difference with 
you is that I actually installed.

Does anybody else see this? If not, what could be wrong with my setup?


Christophe





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

Re: [Spice-devel] [PATCH 02/12] qxl-wddm-dod: Use rendering offload thread

[Christophe de Dinechin]

> On 20 Mar 2017, at 17:37, Christophe de Dinechin <cdupo...@redhat.com 
> <mailto:cdupo...@redhat.com>> wrote:
> 
> Side note: the .gitattribute in that project seems all wrong. It makes source 
> files a pain to edit under Linux or macOS. Why not mark the source files as 
> text? 
> 
> 
>> On 20 Mar 2017, at 13:08, Frediano Ziglio <fzig...@redhat.com 
>> <mailto:fzig...@redhat.com>> wrote:
>> 
>>> 
>>> Instead of sending drawable commands down from presentation
>>> callback, collect drawables objects and pass them to dedicated
>>> thread for processing. This reduce peak load of presentation
>>> callback.
>>> 
>>> Signed-off-by: Javier Celaya <javier.cel...@flexvdi.com 
>>> <mailto:javier.cel...@flexvdi.com>>
>>> Signed-off-by: Yuri Benditovich <yuri.benditov...@daynix.com 
>>> <mailto:yuri.benditov...@daynix.com>>
>>> ---
>>> qxldod/QxlDod.cpp | 43 +--
>>> qxldod/QxlDod.h   |  4 ++--
>>> 2 files changed, 35 insertions(+), 12 deletions(-)
>>> 
>>> diff --git a/qxldod/QxlDod.cpp b/qxldod/QxlDod.cpp
>>> index b952bf9..01de9b3 100755
>>> --- a/qxldod/QxlDod.cpp
>>> +++ b/qxldod/QxlDod.cpp
>>> @@ -3794,11 +3794,20 @@ QxlDevice::ExecutePresentDisplayOnly(
>>> SIZE_T sizeRects = NumDirtyRects*sizeof(RECT);
>>> SIZE_T size = sizeof(DoPresentMemory) + sizeMoves + sizeRects;
>>> 
>>> +QXLDrawable **pDrawables = reinterpret_cast(new
>>> (NonPagedPoolNx) BYTE[sizeof(QXLDrawable *)*(NumDirtyRects + NumMoves +
>>> 1)]);
>> 
>> here would be
>> 
>>  QXLDrawable **pDrawables = new (NonPagedPoolNx) QXLDrawable *[NumDirtyRects 
>> + NumMoves + 1];
>> 
>> is non paged memory needed? Both functions (producer and consumer) are in 
>> paged areas.
>> 
>>> +UINT nIndex = 0;
>>> +
>>> +if (!pDrawables)
>>> +{
>>> +return STATUS_NO_MEMORY;
>>> +}
>>> +
>>> DoPresentMemory* ctx = reinterpret_cast<DoPresentMemory*>
>>> (new (NonPagedPoolNx) BYTE[size]);
>>> 
>> 
>>   DoPresentMemory* ctx = new (NonPagedPoolNx) DoPresentMemory;
> 
> That would be nicer, but apparently, there is extra stuff padded to it:
> 
>>>> SIZE_T size = sizeof(DoPresentMemory) + sizeMoves + sizeRects;
>>>> 
> 
> 
> Also, this part of the code was not changed. It was like this before. But is 
> it necessary ? It’s really borderline with respect to alignment. In one case, 
> we have BYTE-aligned memory, in the other it’s at least sizeof(void *).
> 
> You could use placement new. Assuming non-paged pool:
> 
>   BYTE *storage = new(NonPagedPoolNx) BYTE[size];
>   DoPresentMemory *ctx = new(storage) DoPresentMemory;
> 
> There’s no constructor, apparently. So it does not make much of a difference.
> 
>> 
>> same comments as above
>> 
>>> if (!ctx)
>>> {
>>> +delete[] reinterpret_cast<BYTE*>(pDrawables);
>> 
>> delete[] pDrawables;
>> 
>>> return STATUS_NO_MEMORY;
>>> }
>>> 
>>> @@ -3828,6 +3837,8 @@ QxlDevice::ExecutePresentDisplayOnly(
>>> PMDL mdl = IoAllocateMdl((PVOID)SrcAddr, sizeToMap,  FALSE, FALSE,
>>> NULL);
>>> if(!mdl)
>>> {
>>> +delete[] reinterpret_cast<BYTE*>(ctx);
> 
> There were several leaks of ctx in case of failure before. I suggest a 
> separate patch to fix that. There are many other places where the current 
> patch does not fix them, for instance VgaDevice::GetModeList can leak 
> m_ModeInfo if m_ModeNumbers can’t be allocated.


I’m probably wrong on this. They are freed in the destructor, and freed before 
you can overwrite them. But for local variables like ctx, there are leaks.

Christophe

> 
> 
>>> +delete[] reinterpret_cast<BYTE*>(pDrawables);
>> 
>> similar to above, in this case "delete ctx;”
> 
> There is a risk if, indeed, we store more than an object in it. delete[] and 
> delete are implemented differently by some runtimes (I don’t recall about the 
> Win driver runtime). It is not guaranteed that delete ctx would work reliably 
> if we allocated more than sizeof(DoPresentMemory) bytes. Being able to deal 
> with variable size is the very reason for delete[].
> 
> 
>> 
>>> return STATUS_INSUFFICIENT_RESOURCES;
&

[Spice-devel] Allocation style in QXLDOD

[Christophe de Dinechin]

Hi Vadim,


Looking at the code for QxlDod.cpp, I see allocations that look like this:

5c52e50b (Vadim Rozenfeld 2014-09-02 17:36:27 +1000 3169) 
m_ModeNumbers = reinterpret_cast (new (PagedPool)  BYTE [sizeof 
(USHORT) * ModeCount]);

and corresponding deallocations that look like this:

165b53d4 (Vadim Rozenfeld 2015-03-30 22:57:12 +1100 3154) 
delete [] reinterpret_cast(m_ModeInfo);
165b53d4 (Vadim Rozenfeld 2015-03-30 22:57:12 +1100 3155) 
delete [] reinterpret_cast(m_ModeNumbers);

I was wondering if there was a rationale behind this way of allocating things 
vs the more standard:

m_ModeNumbers = new(PagedPool) USHORT[ModeCount];

and

delete[] m_ModeNumbers;

?

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

[Spice-devel] Gnome vino-server not listening to IPv4

[Christophe de Dinechin]

Hello,


[If you don’t use VNC to access a Linux host, you can safely skip this e-mail]

I recently lost access to three Linux hosts over VNC, and it took me long 
enough to figure out what was going on that I thought I’d share and ask for 
advice. This is recorded as https://bugzilla.redhat.com/show_bug.cgi?id=1437619 
, seems to be related to 
others, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=703009 
.

Symptoms: VNC access to a Linux host does not work. Local access with 
remote-viewer vnc://localhost:5900  works. Remote access 
with remote-viewer vnc://myhost:5900  does not. Doing lsof 
-i -P | grep vino shows that the vino-server is only listening to IPv6.

Apparent cause: In some conditions, which apparently involve localhost 
resolving as ::1, vino-server only listens to IPv6. When this is the case, you 
get:

ddd@muse ~> lsof -i -R | grep vino
vino-serv 3326 1309  ddd   12u  IPv6  75662  0t0  TCP *:rfb (LISTEN)

When it’s working “normally”, you get:

ddd@muse ~> lsof -i -R | grep vino
vino-serv 3326 1309  ddd   12u  IPv4  86485  0t0  TCP muse.dinechin.org:rfb 
(LISTEN)
vino-serv 3326 1309  ddd   14u  IPv6  86486  0t0  TCP muse.dinechin.org:rfb 
(LISTEN)
vino-serv 3326 1309  ddd   15u  IPv6  86487  0t0  TCP muse.dinechin.org:rfb 
(LISTEN)
vino-serv 3326 1309  ddd   16u  IPv4  86488  0t0  TCP 
muse.dinechin.org:rfb->192.168.77.22:54781 (ESTABLISHED)

Workaround: I found two workarounds. You may need one or both, I’ve not seen 
consistent results between my hosts.

#1: Disable localhost resolution to ::1. In my case, this means:
a) Removing the resolution in my local DNS, in my case it was 
in /etc/bind/db.local
b) Commenting out the ::1 entry in /etc/hosts.

#2: Force the server to listen on a specific interface (only had to do 
it on one of my hosts)
a) Run dconf-editor
b) Go to /org/gnome/desktop/remote-access/network-interface
c) Set “Use default value” to off
d) Enter the name of your network card, e.g. enp4s0 for my 
machine, in the “Custom value” field.

Cause of change: I am not sure, because I changed both my DNS (now bind9 on a 
local machine) and did a dnf update. I saw the problem after the update, but it 
may just be because the network restarted, since in at least one case, 
vino-server had not actually been updated.


Hope this helps someone ;-)

Christophe



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

Re: [Spice-devel] [spice-common] log: Add missing stdio.h include

[Christophe de Dinechin]

BTW, putting local headers first makes it possible to detect missing / implicit 
dependencies in the header, i.e.:

#include “macros.h”

#include 
#include 
#include 
#include 

Christophe

> On 31 Mar 2017, at 12:03, Christophe Fergeau  > wrote:
> 
> On Fri, Mar 31, 2017 at 11:50:34AM +0200, Pavel Grunt wrote:
>> On Fri, 2017-03-31 at 05:36 -0400, Frediano Ziglio wrote:
 
 This is needed because spice_printerr uses fprintf/stderr
 ---
  common/log.h | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/common/log.h b/common/log.h
 index 0e03f59..11261ca 100644
 --- a/common/log.h
 +++ b/common/log.h
 @@ -18,6 +18,8 @@
  #ifndef H_SPICE_LOG
  #define H_SPICE_LOG
  
 +#include 
 +
>> per spice style there should not be this empty line
> 
> Looks like more moving around would be needed if we want to be
> consistent with the style guide:
> 
> #include 
> #include 
> #include 
> #include 
> 
> #include "macros.h"
> 
> Christophe
> ___
> 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 v2 1/2] Fix possible multimedia time overflow

[Christophe de Dinechin]

> On 16 Mar 2017, at 11:49, Marc-André Lureau  > wrote:
> 
> Hi
> 
> - Original Message -
>> The multimedia time can easily overflow as is encoded in an
>> unsigned 32 bit and have a unit of milliseconds so it wrap
>> up every 49 days. Use some math that allow the number to overflow
>> without issues.
>> This could caused the client to stop handling streaming and
>> starting only queueing.
>> 
>> Signed-off-by: Frediano Ziglio > >
>> ---
>> This patch should be applied independently on 2/2 as intended to be
>> merged upstream as a fix while 2/2 depends on this as it change same
>> code portions.
>> ---
>> src/channel-display-gst.c   | 11 ++-
>> src/channel-display-mjpeg.c | 14 --
>> src/channel-display-priv.h  | 19 +++
>> 3 files changed, 33 insertions(+), 11 deletions(-)
>> 
>> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
>> index c4190b2..9c62e67 100644
>> --- a/src/channel-display-gst.c
>> +++ b/src/channel-display-gst.c
>> @@ -183,8 +183,9 @@ static void schedule_frame(SpiceGstDecoder *decoder)
>> }
>> 
>> SpiceStreamDataHeader *op = spice_msg_in_parsed(frame->msg);
>> -if (now < op->multi_media_time) {
>> -decoder->timer_id = g_timeout_add(op->multi_media_time - now,
>> +gint32 time_diff = compute_mm_time_diff(op->multi_media_time, now);
>> +if (time_diff >= 0) {
>> +decoder->timer_id = g_timeout_add(time_diff,
>>   display_frame, decoder);
>> } else if (g_queue_get_length(decoder->display_queue) == 1) {
>> /* Still attempt to display the least out of date frame so the
>> @@ -192,8 +193,8 @@ static void schedule_frame(SpiceGstDecoder *decoder)
>>  */
>> decoder->timer_id = g_timeout_add(0, display_frame, decoder);
>> } else {
>> -SPICE_DEBUG("%s: rendering too late by %u ms (ts: %u, mmtime:
>> %u), dropping",
>> -__FUNCTION__, now - op->multi_media_time,
>> +SPICE_DEBUG("%s: rendering too late by %d ms (ts: %u, mmtime:
>> %u), dropping",
>> +__FUNCTION__, -time_diff,
>> op->multi_media_time, now);
>> stream_dropped_frame_on_playback(decoder->base.stream);
>> g_queue_pop_head(decoder->display_queue);
>> @@ -431,7 +432,7 @@ static gboolean
>> spice_gst_decoder_queue_frame(VideoDecoder *video_decoder,
>> }
>> 
>> SpiceStreamDataHeader *frame_op = spice_msg_in_parsed(frame_msg);
>> -if (frame_op->multi_media_time < decoder->last_mm_time) {
>> +if (compute_mm_time_diff(frame_op->multi_media_time,
>> decoder->last_mm_time) < 0) {
>> SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
>> " resetting stream, id %u",
>> frame_op->multi_media_time,
>> diff --git a/src/channel-display-mjpeg.c b/src/channel-display-mjpeg.c
>> index 722494e..1b7373b 100644
>> --- a/src/channel-display-mjpeg.c
>> +++ b/src/channel-display-mjpeg.c
>> @@ -195,15 +195,15 @@ static void mjpeg_decoder_schedule(MJpegDecoder
>> *decoder)
>> do {
>> if (frame_msg) {
>> SpiceStreamDataHeader *op = spice_msg_in_parsed(frame_msg);
>> -if (time <= op->multi_media_time) {
>> -guint32 d = op->multi_media_time - time;
>> +gint32 time_diff = compute_mm_time_diff(op->multi_media_time,
>> time);
>> +if (time_diff >= 0) {
>> decoder->cur_frame_msg = frame_msg;
>> -decoder->timer_id = g_timeout_add(d,
>> mjpeg_decoder_decode_frame, decoder);
>> +decoder->timer_id = g_timeout_add(time_diff,
>> mjpeg_decoder_decode_frame, decoder);
>> break;
>> }
>> 
>> -SPICE_DEBUG("%s: rendering too late by %u ms (ts: %u, mmtime:
>> %u), dropping ",
>> -__FUNCTION__, time - op->multi_media_time,
>> +SPICE_DEBUG("%s: rendering too late by %d ms (ts: %u, mmtime:
>> %u), dropping ",
>> +__FUNCTION__, -time_diff,
>> op->multi_media_time, time);
>> stream_dropped_frame_on_playback(decoder->base.stream);
>> spice_msg_in_unref(frame_msg);
>> @@ -249,7 +249,9 @@ static gboolean mjpeg_decoder_queue_frame(VideoDecoder
>> *video_decoder,
>> SpiceStreamDataHeader *last_op, *frame_op;
>> last_op = spice_msg_in_parsed(last_msg);
>> frame_op = spice_msg_in_parsed(frame_msg);
>> -if (frame_op->multi_media_time < last_op->multi_media_time) {
>> +gint32 time_diff =
>> +compute_mm_time_diff(frame_op->multi_media_time,
>> last_op->multi_media_time);
>> +if (time_diff < 0) {
>> /* This should really not happen */
>> 

Re: [Spice-devel] [PATCH spice-server] build: Fix some indentation issue on Makefile.am

[Christophe de Dinechin]

On 16 Mar 2017, at 17:08, Christophe Fergeau  wrote:
> 
> On Thu, Mar 16, 2017 at 10:26:24AM -0500, Jonathon Jongsma wrote:
>> ACK for consistency (although I agree with you: I don't like this style
>> of lining up the slashes. I'd rather just place them directly after the
>> filename).
> 
> Oh, just kill these then if I'm the only one liking them :)

Nope. Like that too. Must be a Christophe / French thing…

Christophe

> 
> Christophe
> 
>> 
>> Jonathon
>> 
>> On Tue, 2017-03-14 at 09:25 +, Frediano Ziglio wrote:
>>> Signed-off-by: Frediano Ziglio 
>>> ---
>>> server/Makefile.am | 52 ++
>>> --
>>> 1 file changed, 26 insertions(+), 26 deletions(-)
>>> 
>>> I still think this format is leading to misindentation but at least
>>> this
>>> fix some ugly ones.
>>> 
>>> diff --git a/server/Makefile.am b/server/Makefile.am
>>> index 49c0822..840f63e 100644
>>> --- a/server/Makefile.am
>>> +++ b/server/Makefile.am
>>> @@ -83,13 +83,13 @@ libserver_la_SOURCES =  
>>> \
>>> event-loop.c\
>>> glz-encoder.c   \
>>> glz-encoder.h   \
>>> -   glz-encoder-dict.c  \
>>> -   glz-encoder-dict.h  \
>>> -   glz-encoder-priv.h  \
>>> +   glz-encoder-dict.c  \
>>> +   glz-encoder-dict.h  \
>>> +   glz-encoder-priv.h  \
>>> inputs-channel.c\
>>> inputs-channel.h\
>>> -   inputs-channel-client.c \
>>> -   inputs-channel-client.h \
>>> +   inputs-channel-client.c \
>>> +   inputs-channel-client.h \
>>> jpeg-encoder.c  \
>>> jpeg-encoder.h  \
>>> main-channel.c  \
>>> @@ -112,7 +112,7 @@ libserver_la_SOURCES =  
>>> \
>>> red-qxl.h   \
>>> main-dispatcher.c   \
>>> main-dispatcher.h   \
>>> -   migration-protocol.h\
>>> +   migration-protocol.h\
>>> memslot.c   \
>>> memslot.h   \
>>> red-parse-qxl.c \
>>> @@ -136,9 +136,9 @@ libserver_la_SOURCES =  
>>> \
>>> reds-private.h  \
>>> reds-stream.c   \
>>> reds-stream.h   \
>>> -   sw-canvas.c \
>>> -   sound.c \
>>> -   sound.h \
>>> +   sw-canvas.c \
>>> +   sound.c \
>>> +   sound.h \
>>> stat.h  \
>>> stat-file.c \
>>> stat-file.h \
>>> @@ -146,48 +146,48 @@ libserver_la_SOURCES =
>>> \
>>> video-encoder.h \
>>> zlib-encoder.c  \
>>> zlib-encoder.h  \
>>> -   image-cache.h   \
>>> -   image-cache.c   \
>>> +   image-cache.h   \
>>> +   image-cache.c   \
>>> pixmap-cache.h  \
>>> pixmap-cache.c  \
>>> -   tree.h  \
>>> -   tree.c  \
>>> +   tree.h  \
>>> +   tree.c  \
>>> spice-bitmap-utils.h\
>>> spice-bitmap-utils.c\
>>> utils.c \
>>> utils.h \
>>> -   stream.c\
>>> -   stream.h\
>>> +   stream.c\
>>> +   stream.h\
>>> dcc.c   \
>>> -   dcc-send.c  \
>>> +   dcc-send.c  \
>>> dcc.h   \
>>> display-limits.h\
>>> dcc-private.h   \
>>> -   image-encoders.c\
>>> -   image-encoders.h\
>>> +   image-encoders.c\
>>> +   image-encoders.h\
>>> glib-compat.h   \
>>> -   $(spice_built_sources)  \
>>> +   $(spice_built_sources)  \
>>> $(NULL)
>>> 
>>> if HAVE_LZ4
>>> -libserver_la_SOURCES +=\
>>> +libserver_la_SOURCES +=  

Re: [Spice-devel] [PATCH 02/12] qxl-wddm-dod: Use rendering offload thread

[Christophe de Dinechin]

> On 20 Mar 2017, at 19:03, Frediano Ziglio  > wrote:
> 
> 
> Side note: the .gitattribute in that project seems all wrong. It makes source 
> files a pain to edit under Linux or macOS. Why not mark the source files as 
> text? 
> To avoid cr/lf conversions.

But we want CR/LF conversions for text files. That’s the whole point.

> If you can find good flags to make git Windows and git Unix to work you are 
> welcome.
> Got mad to try, you fix a tool and you break another.

I did that recently on another project. text=auto does work. I guess there was 
some other problem at the time. You mention multiple tools. Do you remember 
which one broke?

> I have no problems with Linux, my editor just handle DOS files as DOS.

So does Emacs, but it shows additional ^M within the file if CR/LF is 
inconsistent throughout the file, as it the case here, presumably because the 
.gitattributes was added in the middle of the life of the project without first 
making the files consistent.


Thanks,
Christophe
> 
> On 20 Mar 2017, at 13:08, Frediano Ziglio  > wrote:
> 
> 
> Instead of sending drawable commands down from presentation
> callback, collect drawables objects and pass them to dedicated
> thread for processing. This reduce peak load of presentation
> callback.
> 
> Signed-off-by: Javier Celaya  >
> Signed-off-by: Yuri Benditovich  >
> ---
> qxldod/QxlDod.cpp | 43 +--
> qxldod/QxlDod.h   |  4 ++--
> 2 files changed, 35 insertions(+), 12 deletions(-)
> 
> diff --git a/qxldod/QxlDod.cpp b/qxldod/QxlDod.cpp
> index b952bf9..01de9b3 100755
> --- a/qxldod/QxlDod.cpp
> +++ b/qxldod/QxlDod.cpp
> @@ -3794,11 +3794,20 @@ QxlDevice::ExecutePresentDisplayOnly(
> SIZE_T sizeRects = NumDirtyRects*sizeof(RECT);
> SIZE_T size = sizeof(DoPresentMemory) + sizeMoves + sizeRects;
> 
> +QXLDrawable **pDrawables = reinterpret_cast(new
> (NonPagedPoolNx) BYTE[sizeof(QXLDrawable *)*(NumDirtyRects + NumMoves +
> 1)]);
> 
> here would be
> 
>  QXLDrawable **pDrawables = new (NonPagedPoolNx) QXLDrawable *[NumDirtyRects 
> + NumMoves + 1];
> 
> is non paged memory needed? Both functions (producer and consumer) are in 
> paged areas.
> 
> +UINT nIndex = 0;
> +
> +if (!pDrawables)
> +{
> +return STATUS_NO_MEMORY;
> +}
> +
> DoPresentMemory* ctx = reinterpret_cast
> (new (NonPagedPoolNx) BYTE[size]);
> 
> 
>   DoPresentMemory* ctx = new (NonPagedPoolNx) DoPresentMemory;
> 
> That would be nicer, but apparently, there is extra stuff padded to it:
> 
> SIZE_T size = sizeof(DoPresentMemory) + sizeMoves + sizeRects;
> 
> 
> Also, this part of the code was not changed. It was like this before. But is 
> it necessary ? It’s really borderline with respect to alignment. In one case, 
> we have BYTE-aligned memory, in the other it’s at least sizeof(void *).
> 
> You could use placement new. Assuming non-paged pool:
> 
>   BYTE *storage = new(NonPagedPoolNx) BYTE[size];
>   DoPresentMemory *ctx = new(storage) DoPresentMemory;
> 
> There’s no constructor, apparently. So it does not make much of a difference.
> Looking at the code it looks quite weird, a ctx is allocated in the function, 
> then at the end freed,
> I found these comments:
> 
> // Alternate between synch and asynch execution, for demonstrating 
> // that a real hardware implementation can do either
> ...
> 
> // Save Mdl to unmap and unlock the pages in worker thread
> ...
> 
> // copy moves and update pointer
> ...
> 
> // copy dirty rects and update pointer
> 
> 
> apparently this is all due to the initial code (from a Microsoft example) 
> that was marshalling this
> call to a worker thread.
> However now that we are going to introduce a worker thread this looks 
> misleading.
> I would remove comments and code. For instance there's no need to copy Moves 
> & DirtyRect
> and DoPresentMemory can be allocated just in the stack (or even better 
> removed).
> 
> same comments as above
> 
> if (!ctx)
> {
> +delete[] reinterpret_cast(pDrawables);
> 
> delete[] pDrawables;
> 
> return STATUS_NO_MEMORY;
> }
> 
> @@ -3828,6 +3837,8 @@ QxlDevice::ExecutePresentDisplayOnly(
> PMDL mdl = IoAllocateMdl((PVOID)SrcAddr, sizeToMap,  FALSE, FALSE,
> NULL);
> if(!mdl)
> {
> +delete[] reinterpret_cast(ctx);
> 
> There were several leaks of ctx in case of failure before. I suggest a 
> separate patch to fix that. There are many other places where the current 
> patch does not fix them, for instance VgaDevice::GetModeList can leak 
> m_ModeInfo if m_ModeNumbers can’t be allocated.
> Can you write some patches about these? These 

Re: [Spice-devel] [PATCH 02/12] qxl-wddm-dod: Use rendering offload thread

[Christophe de Dinechin]

> On 21 Mar 2017, at 13:59, Yuri Benditovich  
> wrote:
> 
> 
> 
> On Mon, Mar 20, 2017 at 2:08 PM, Frediano Ziglio  > wrote:
> >
> > Instead of sending drawable commands down from presentation
> > callback, collect drawables objects and pass them to dedicated
> > thread for processing. This reduce peak load of presentation
> > callback.
> >
> > Signed-off-by: Javier Celaya  > >
> > Signed-off-by: Yuri Benditovich  > >
> > ---
> >  qxldod/QxlDod.cpp | 43 +--
> >  qxldod/QxlDod.h   |  4 ++--
> >  2 files changed, 35 insertions(+), 12 deletions(-)
> >
> > diff --git a/qxldod/QxlDod.cpp b/qxldod/QxlDod.cpp
> > index b952bf9..01de9b3 100755
> > --- a/qxldod/QxlDod.cpp
> > +++ b/qxldod/QxlDod.cpp
> > @@ -3794,11 +3794,20 @@ QxlDevice::ExecutePresentDisplayOnly(
> >  SIZE_T sizeRects = NumDirtyRects*sizeof(RECT);
> >  SIZE_T size = sizeof(DoPresentMemory) + sizeMoves + sizeRects;
> >
> > +QXLDrawable **pDrawables = reinterpret_cast(new
> > (NonPagedPoolNx) BYTE[sizeof(QXLDrawable *)*(NumDirtyRects + NumMoves +
> > 1)]);
> 
> here would be
> 
>   QXLDrawable **pDrawables = new (NonPagedPoolNx) QXLDrawable *[NumDirtyRects 
> + NumMoves + 1];
> 
> is non paged memory needed? Both functions (producer and consumer) are in 
> paged areas.
> 
> > +UINT nIndex = 0;
> > +
> > +if (!pDrawables)
> > +{
> > +return STATUS_NO_MEMORY;
> > +}
> > +
> >  DoPresentMemory* ctx = reinterpret_cast
> >  (new (NonPagedPoolNx) BYTE[size]);
> >
> 
>DoPresentMemory* ctx = new (NonPagedPoolNx) DoPresentMemory;
> 
> Current commit intentionally does not change this, to make clear what is 
> changed.

Good.

If we use a non-paged placement new, shouldn’t we use a corresponding placement 
delete?


> Without changes in the code we can't just allocate less memory, as trailing 
> RECT structures are used for
> unneeded copy from parameters.
> Removal of this completely unneeded 'ctx' is planned for further commits 
> after all the HCK-related work is done.

>  
> 
> same comments as above
> 
> >  if (!ctx)
> >  {
> > +delete[] reinterpret_cast(pDrawables);
> 
> delete[] pDrawables;
> 
> >  return STATUS_NO_MEMORY;
> >  }
> >
> > @@ -3828,6 +3837,8 @@ QxlDevice::ExecutePresentDisplayOnly(
> >  PMDL mdl = IoAllocateMdl((PVOID)SrcAddr, sizeToMap,  FALSE, FALSE,
> >  NULL);
> >  if(!mdl)
> >  {
> > +delete[] reinterpret_cast(ctx);
> > +delete[] reinterpret_cast(pDrawables);
> 
> similar to above, in this case "delete ctx;"
> 
> >  return STATUS_INSUFFICIENT_RESOURCES;
> >  }
> >
> > @@ -3844,6 +3855,8 @@ QxlDevice::ExecutePresentDisplayOnly(
> >  {
> >  Status = GetExceptionCode();
> >  IoFreeMdl(mdl);
> > +delete[] reinterpret_cast(ctx);
> > +delete[] reinterpret_cast(pDrawables);
> 
> ditto
> 
> >  return Status;
> >  }
> >
> > @@ -3857,6 +3870,8 @@ QxlDevice::ExecutePresentDisplayOnly(
> >  Status = STATUS_INSUFFICIENT_RESOURCES;
> >  MmUnlockPages(mdl);
> >  IoFreeMdl(mdl);
> > +delete[] reinterpret_cast(ctx);
> > +delete[] reinterpret_cast(pDrawables);
> 
> ditto
> 
> >  return Status;
> >  }
> >
> > @@ -3922,7 +3937,9 @@ QxlDevice::ExecutePresentDisplayOnly(
> >  DbgPrint(TRACE_LEVEL_INFORMATION, ("--- %d SourcePoint.x = %ld,
> >  SourcePoint.y = %ld, DestRect.bottom = %ld, DestRect.left = %ld,
> >  DestRect.right = %ld, DestRect.top = %ld\n",
> >  i , pSourcePoint->x, pSourcePoint->y, pDestRect->bottom,
> >  pDestRect->left, pDestRect->right, pDestRect->top));
> >
> > -CopyBits(*pDestRect, *pSourcePoint);
> > +pDrawables[nIndex] = CopyBits(*pDestRect, *pSourcePoint);
> > +
> > +if (pDrawables[nIndex]) nIndex++;
> >  }
> >
> >  // Copy all the dirty rects from source image to video frame buffer.
> > @@ -3936,11 +3953,13 @@ QxlDevice::ExecutePresentDisplayOnly(
> >  DbgPrint(TRACE_LEVEL_INFORMATION, ("--- %d pDirtyRect->bottom = 
> > %ld,
> >  pDirtyRect->left = %ld, pDirtyRect->right = %ld, pDirtyRect->top =
> >  %ld\n",
> >  i, pDirtyRect->bottom, pDirtyRect->left, pDirtyRect->right,
> >  pDirtyRect->top));
> >
> > -BltBits(,
> > +pDrawables[nIndex] = BltBits(,
> >  ,
> >  1,
> >  pDirtyRect,
> >  );
> > +
> > +if (pDrawables[nIndex]) nIndex++;
> >  }
> >
> >  // Unmap unmap and unlock the pages.
> > @@ -3951,6 

Re: [Spice-devel] [PATCH 02/12] qxl-wddm-dod: Use rendering offload thread

[Christophe de Dinechin]

> On 21 Mar 2017, at 11:51, Frediano Ziglio  > wrote:
> So does Emacs, but it shows additional ^M within the file if CR/LF is 
> inconsistent throughout the file, as it the case here, presumably because the 
> .gitattributes was added in the middle of the life of the project without 
> first making the files consistent.
> There's no mix in single files, I have a script to test this issue. 
> gitattributes was added after making each file consistent but all files are 
> not consistent (as stated above).
> Probably you applied from the mail which tend to strip CRs at the end so you 
> got the inconsistency.

Not just at the end, it strips all CR. But you are right, only the patched file 
was inconsistent.

Christophe

> 
> Thanks,
> Christophe
> 
> Frediano
> 
> On 20 Mar 2017, at 13:08, Frediano Ziglio  > wrote:
> 
> 
> Instead of sending drawable commands down from presentation
> callback, collect drawables objects and pass them to dedicated
> thread for processing. This reduce peak load of presentation
> callback.
> 
> Signed-off-by: Javier Celaya  >
> Signed-off-by: Yuri Benditovich  >
> ---
> qxldod/QxlDod.cpp | 43 +--
> qxldod/QxlDod.h   |  4 ++--
> 2 files changed, 35 insertions(+), 12 deletions(-)
> 
> diff --git a/qxldod/QxlDod.cpp b/qxldod/QxlDod.cpp
> index b952bf9..01de9b3 100755
> --- a/qxldod/QxlDod.cpp
> +++ b/qxldod/QxlDod.cpp
> @@ -3794,11 +3794,20 @@ QxlDevice::ExecutePresentDisplayOnly(
> SIZE_T sizeRects = NumDirtyRects*sizeof(RECT);
> SIZE_T size = sizeof(DoPresentMemory) + sizeMoves + sizeRects;
> 
> +QXLDrawable **pDrawables = reinterpret_cast(new
> (NonPagedPoolNx) BYTE[sizeof(QXLDrawable *)*(NumDirtyRects + NumMoves +
> 1)]);
> 
> here would be
> 
>  QXLDrawable **pDrawables = new (NonPagedPoolNx) QXLDrawable *[NumDirtyRects 
> + NumMoves + 1];
> 
> is non paged memory needed? Both functions (producer and consumer) are in 
> paged areas.
> 
> +UINT nIndex = 0;
> +
> +if (!pDrawables)
> +{
> +return STATUS_NO_MEMORY;
> +}
> +
> DoPresentMemory* ctx = reinterpret_cast
> (new (NonPagedPoolNx) BYTE[size]);
> 
> 
>   DoPresentMemory* ctx = new (NonPagedPoolNx) DoPresentMemory;
> 
> That would be nicer, but apparently, there is extra stuff padded to it:
> 
> SIZE_T size = sizeof(DoPresentMemory) + sizeMoves + sizeRects;
> 
> 
> Also, this part of the code was not changed. It was like this before. But is 
> it necessary ? It’s really borderline with respect to alignment. In one case, 
> we have BYTE-aligned memory, in the other it’s at least sizeof(void *).
> 
> You could use placement new. Assuming non-paged pool:
> 
>  BYTE *storage = new(NonPagedPoolNx) BYTE[size];
>  DoPresentMemory *ctx = new(storage) DoPresentMemory;
> 
> There’s no constructor, apparently. So it does not make much of a difference.
> Looking at the code it looks quite weird, a ctx is allocated in the function, 
> then at the end freed,
> I found these comments:
> 
> // Alternate between synch and asynch execution, for demonstrating 
> // that a real hardware implementation can do either
> ...
> 
> // Save Mdl to unmap and unlock the pages in worker thread
> ...
> 
> // copy moves and update pointer
> ...
> 
> // copy dirty rects and update pointer
> 
> 
> apparently this is all due to the initial code (from a Microsoft example) 
> that was marshalling this
> call to a worker thread.
> However now that we are going to introduce a worker thread this looks 
> misleading.
> I would remove comments and code. For instance there's no need to copy Moves 
> & DirtyRect
> and DoPresentMemory can be allocated just in the stack (or even better 
> removed).
> 
> same comments as above
> 
> if (!ctx)
> {
> +delete[] reinterpret_cast(pDrawables);
> 
> delete[] pDrawables;
> 
> return STATUS_NO_MEMORY;
> }
> 
> @@ -3828,6 +3837,8 @@ QxlDevice::ExecutePresentDisplayOnly(
> PMDL mdl = IoAllocateMdl((PVOID)SrcAddr, sizeToMap,  FALSE, FALSE,
> NULL);
> if(!mdl)
> {
> +delete[] reinterpret_cast(ctx);
> 
> There were several leaks of ctx in case of failure before. I suggest a 
> separate patch to fix that. There are many other places where the current 
> patch does not fix them, for instance VgaDevice::GetModeList can leak 
> m_ModeInfo if m_ModeNumbers can’t be allocated.
> Can you write some patches about these? These specifically seem not really 
> related.
> 
> +delete[] reinterpret_cast(pDrawables);
> 
> similar to above, in this case "delete ctx;”
> 
> There is a risk if, indeed, we store more than an object in it. delete[] and 
> delete are implemented 

Re: [Spice-devel] [PATCH 02/12] qxl-wddm-dod: Use rendering offload thread

[Christophe de Dinechin]

Side note: the .gitattribute in that project seems all wrong. It makes source 
files a pain to edit under Linux or macOS. Why not mark the source files as 
text? 


> On 20 Mar 2017, at 13:08, Frediano Ziglio  > wrote:
> 
>> 
>> Instead of sending drawable commands down from presentation
>> callback, collect drawables objects and pass them to dedicated
>> thread for processing. This reduce peak load of presentation
>> callback.
>> 
>> Signed-off-by: Javier Celaya > >
>> Signed-off-by: Yuri Benditovich > >
>> ---
>> qxldod/QxlDod.cpp | 43 +--
>> qxldod/QxlDod.h   |  4 ++--
>> 2 files changed, 35 insertions(+), 12 deletions(-)
>> 
>> diff --git a/qxldod/QxlDod.cpp b/qxldod/QxlDod.cpp
>> index b952bf9..01de9b3 100755
>> --- a/qxldod/QxlDod.cpp
>> +++ b/qxldod/QxlDod.cpp
>> @@ -3794,11 +3794,20 @@ QxlDevice::ExecutePresentDisplayOnly(
>> SIZE_T sizeRects = NumDirtyRects*sizeof(RECT);
>> SIZE_T size = sizeof(DoPresentMemory) + sizeMoves + sizeRects;
>> 
>> +QXLDrawable **pDrawables = reinterpret_cast(new
>> (NonPagedPoolNx) BYTE[sizeof(QXLDrawable *)*(NumDirtyRects + NumMoves +
>> 1)]);
> 
> here would be
> 
>  QXLDrawable **pDrawables = new (NonPagedPoolNx) QXLDrawable *[NumDirtyRects 
> + NumMoves + 1];
> 
> is non paged memory needed? Both functions (producer and consumer) are in 
> paged areas.
> 
>> +UINT nIndex = 0;
>> +
>> +if (!pDrawables)
>> +{
>> +return STATUS_NO_MEMORY;
>> +}
>> +
>> DoPresentMemory* ctx = reinterpret_cast
>> (new (NonPagedPoolNx) BYTE[size]);
>> 
> 
>   DoPresentMemory* ctx = new (NonPagedPoolNx) DoPresentMemory;

That would be nicer, but apparently, there is extra stuff padded to it:

>>> SIZE_T size = sizeof(DoPresentMemory) + sizeMoves + sizeRects;
>>> 


Also, this part of the code was not changed. It was like this before. But is it 
necessary ? It’s really borderline with respect to alignment. In one case, we 
have BYTE-aligned memory, in the other it’s at least sizeof(void *).

You could use placement new. Assuming non-paged pool:

BYTE *storage = new(NonPagedPoolNx) BYTE[size];
DoPresentMemory *ctx = new(storage) DoPresentMemory;

There’s no constructor, apparently. So it does not make much of a difference.

> 
> same comments as above
> 
>> if (!ctx)
>> {
>> +delete[] reinterpret_cast(pDrawables);
> 
> delete[] pDrawables;
> 
>> return STATUS_NO_MEMORY;
>> }
>> 
>> @@ -3828,6 +3837,8 @@ QxlDevice::ExecutePresentDisplayOnly(
>> PMDL mdl = IoAllocateMdl((PVOID)SrcAddr, sizeToMap,  FALSE, FALSE,
>> NULL);
>> if(!mdl)
>> {
>> +delete[] reinterpret_cast(ctx);

There were several leaks of ctx in case of failure before. I suggest a separate 
patch to fix that. There are many other places where the current patch does not 
fix them, for instance VgaDevice::GetModeList can leak m_ModeInfo if 
m_ModeNumbers can’t be allocated.


>> +delete[] reinterpret_cast(pDrawables);
> 
> similar to above, in this case "delete ctx;”

There is a risk if, indeed, we store more than an object in it. delete[] and 
delete are implemented differently by some runtimes (I don’t recall about the 
Win driver runtime). It is not guaranteed that delete ctx would work reliably 
if we allocated more than sizeof(DoPresentMemory) bytes. Being able to deal 
with variable size is the very reason for delete[].


> 
>> return STATUS_INSUFFICIENT_RESOURCES;
>> }
>> 
>> @@ -3844,6 +3855,8 @@ QxlDevice::ExecutePresentDisplayOnly(
>> {
>> Status = GetExceptionCode();
>> IoFreeMdl(mdl);
>> +delete[] reinterpret_cast(ctx);
>> +delete[] reinterpret_cast(pDrawables);



> ditto
> 
>> return Status;
>> }
>> 
>> @@ -3857,6 +3870,8 @@ QxlDevice::ExecutePresentDisplayOnly(
>> Status = STATUS_INSUFFICIENT_RESOURCES;
>> MmUnlockPages(mdl);
>> IoFreeMdl(mdl);
>> +delete[] reinterpret_cast(ctx);
>> +delete[] reinterpret_cast(pDrawables);
> 
> ditto


> 
>> return Status;
>> }
>> 
>> @@ -3922,7 +3937,9 @@ QxlDevice::ExecutePresentDisplayOnly(
>> DbgPrint(TRACE_LEVEL_INFORMATION, ("--- %d SourcePoint.x = %ld,
>> SourcePoint.y = %ld, DestRect.bottom = %ld, DestRect.left = %ld,
>> DestRect.right = %ld, DestRect.top = %ld\n",
>> i , pSourcePoint->x, pSourcePoint->y, pDestRect->bottom,
>> pDestRect->left, pDestRect->right, pDestRect->top));
>> 
>> -CopyBits(*pDestRect, *pSourcePoint);
>> +pDrawables[nIndex] = CopyBits(*pDestRect, *pSourcePoint);
>> 

Re: [Spice-devel] [spice-space-pages PATCH v2] Spice Proxy documentation

[Christophe de Dinechin]

> On 19 Mar 2017, at 13:54, Uri Lublin  wrote:
> 
> Signed-off-by: Uri Lublin 
> 
> 
> Changes since v1:
> 1. :modified: was removed from the top
> 2. 2 ways to set up proxy -- are numbered
> 3. Comment added to not use http_proxy
> 4. "Installation (Fedora)" section removed.
> 5. A misplaced "the" was removed.
> 
> --
> proxy.rst | 95 +++
> 1 file changed, 95 insertions(+)
> create mode 100644 proxy.rst
> 
> diff --git a/proxy.rst b/proxy.rst
> new file mode 100644
> index 000..9332cd5
> --- /dev/null
> +++ b/proxy.rst
> @@ -0,0 +1,95 @@
> +Spice Proxy
> +###
> +
> +:slug: spice-proxy
> +
> +Introduction
> +
> +
> +Spice client (remote-viewer) supports connecting to the server via an http 
> proxy.
> +This may be desirable for cases when the client does not have direct access

I would write either “in cases where the client” or just “when the client”. Are 
there native english speakers on the list to confirm/infirm?


> +to the server.
> +
> +Configuring the Client
> +++
> +
> +Proxy Format
> +
> +[protocol://]proxy-host[:proxy-port]
> +
> +.. code-block:: sh
> +
> +   for example: http://10.0.15.50:3128
> +
> +There are two ways to tell the client to connect via an http proxy:
> +
> +1. SPICE_PROXY environment variable
> +^^^
> +A SPICE_PROXY environment variable tells remote-viewer
> +to connect to the spice-server via a proxy-server
> +
> +.. code-block:: sh
> +
> +   export SPICE_PROXY="http://10.0.15.50:3128;
> +
> +(Please do not use "http_proxy" as it is not currently supported)

Just curious, why not? It makes sense to have SPICE_PROXY to override if you 
need to. But why not support http_proxy as well?

> +
> +2. proxy key in a vv-file (under [virt-viewer])
> +^^^
> +A proxy key in a vv-file tells remote-viewer to
> +connect to the spice-server via a proxy-server
> +
> +.. code-block:: sh
> +
> +   [virt-viewer]
> +   proxy=http://10.0.15.50:3128
> +
> +
> +Configuring the proxy server (squid as an example)
> +++
> +Squid (squid-cache.org) can be used as a proxy server.
> +
> +This is just an example.
> +There are other configurations possible, and other proxy
> +servers.
> +Configuration should be done according to requirements.
> +Firewall, if exists, may need to be configured as well.
> +
> +
> +Example Configuration (Fedora)
> +^^
> +For information about configuring Squid, please take a look
> +at squid documentation.
> +I looked at http://wiki.squid-cache.org/SquidFaq/SquidAcl.
> +
> +Let's assume there are two hosts (hypervisors) with
> +IP addresses 10.0.0.1 and 10.0.0.2, and both
> +use ports 5900 and 5901 for Spice.
> +A possible configuration may be (in /etc/squid/squid.conf):
> +
> +.. code-block:: sh
> +
> +   acl SPICE_HOSTS 10.0.0.1 10.0.0.2
> +   acl SPICE_PORTS 5900 5901
> +   http_access allow SPICE_HOSTS
> +   http_access allow SPICE_PORTS
> +   http_access deny all
> +
> +allow these hosts and ports but nothing else.
> +
> +
> +Running the client
> +++
> +Once the proxy is set up as described above, run the client as usual, e.g
> +
> +.. code-block:: sh
> +
> +   remote-viewer console.vv
> +
> +or
> +
> +.. code-block:: sh
> +
> +   remote-viewer spice://10.0.0.1:5901
> +
> +
> -- 
> 2.9.3
> 
> ___
> 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-space-pages PATCH] home.rst: s/and and/and/

[Christophe de Dinechin]

> On 19 Mar 2017, at 15:22, Uri Lublin  wrote:
> 
> Reported-by: romulous75 (on IRC)
> 
> Signed-off-by: Uri Lublin 
> ---
> home.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/home.rst b/home.rst
> index 7bef988..36fe95e 100644
> --- a/home.rst
> +++ b/home.rst
> @@ -21,7 +21,7 @@ audio, share usb devices and share folders without 
> complications.
> 
> SPICE could be divided into 4 different components: Protocol, Client, Server
> and Guest. The protocol is the specification in the communication of the three

Shouldn’t that be “the specification of the communication” rather than “in”?


> -other components; A client such as remote-viewer is responsible to send data 
> and
> +other components; A client such as remote-viewer is responsible to send data
> and translate the data from the Virtual Machine (VM) so you can interact with 
> it;
> The SPICE server is the library used by the hypervisor in order to share the 
> VM
> under SPICE protocol; And finally, the Guest side is all the software that 
> must
> -- 
> 2.9.3
> 
> ___
> 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 1/2] Fix possible multimedia time overflow

[Christophe de Dinechin]

> On 16 Mar 2017, at 11:56, Frediano Ziglio  > wrote:
> 
>> 
>> - Original Message -
 
 Hi
 
 - Original Message -
> The multimedia time can easily overflow as is encoded in an
> unsigned 32 bit and have a unit of milliseconds so it wrap
> up every 49 days. Use some math that allow the number to overflow
> without issues.
> This could caused the client to stop handling streaming and
> starting only queueing.
> 
> Signed-off-by: Frediano Ziglio  >
> ---
> src/channel-display-gst.c   | 11 ++-
> src/channel-display-mjpeg.c | 14 --
> src/channel-display-priv.h  | 15 +++
> 3 files changed, 29 insertions(+), 11 deletions(-)
> 
> This patch should be applied independently on 2/2 as intended to be
> merged upstream as a fix while 2/2 depends on this as it change same
> code portions.
> 
> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
> index c4190b2..9c62e67 100644
> --- a/src/channel-display-gst.c
> +++ b/src/channel-display-gst.c
> @@ -183,8 +183,9 @@ static void schedule_frame(SpiceGstDecoder
> *decoder)
> }
> 
> SpiceStreamDataHeader *op = spice_msg_in_parsed(frame->msg);
> -if (now < op->multi_media_time) {
> -decoder->timer_id = g_timeout_add(op->multi_media_time -
> now,
> +gint32 time_diff = compute_mm_time_diff(op->multi_media_time,
> now);
> +if (time_diff >= 0) {
> +decoder->timer_id = g_timeout_add(time_diff,
>   display_frame, decoder);
> } else if (g_queue_get_length(decoder->display_queue) == 1) {
> /* Still attempt to display the least out of date frame so
> the
> @@ -192,8 +193,8 @@ static void schedule_frame(SpiceGstDecoder
> *decoder)
>  */
> decoder->timer_id = g_timeout_add(0, display_frame,
> decoder);
> } else {
> -SPICE_DEBUG("%s: rendering too late by %u ms (ts: %u,
> mmtime:
> %u), dropping",
> -__FUNCTION__, now - op->multi_media_time,
> +SPICE_DEBUG("%s: rendering too late by %d ms (ts: %u,
> mmtime:
> %u), dropping",
> +__FUNCTION__, -time_diff,
> op->multi_media_time, now);
> stream_dropped_frame_on_playback(decoder->base.stream);
> g_queue_pop_head(decoder->display_queue);
> @@ -431,7 +432,7 @@ static gboolean
> spice_gst_decoder_queue_frame(VideoDecoder *video_decoder,
> }
> 
> SpiceStreamDataHeader *frame_op = spice_msg_in_parsed(frame_msg);
> -if (frame_op->multi_media_time < decoder->last_mm_time) {
> +if (compute_mm_time_diff(frame_op->multi_media_time,
> decoder->last_mm_time) < 0) {
> SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
> " resetting stream, id %u",
> frame_op->multi_media_time,
> diff --git a/src/channel-display-mjpeg.c b/src/channel-display-mjpeg.c
> index 722494e..1b7373b 100644
> --- a/src/channel-display-mjpeg.c
> +++ b/src/channel-display-mjpeg.c
> @@ -195,15 +195,15 @@ static void mjpeg_decoder_schedule(MJpegDecoder
> *decoder)
> do {
> if (frame_msg) {
> SpiceStreamDataHeader *op =
> spice_msg_in_parsed(frame_msg);
> -if (time <= op->multi_media_time) {
> -guint32 d = op->multi_media_time - time;
> +gint32 time_diff =
> compute_mm_time_diff(op->multi_media_time,
> time);
> +if (time_diff >= 0) {
> decoder->cur_frame_msg = frame_msg;
> -decoder->timer_id = g_timeout_add(d,
> mjpeg_decoder_decode_frame, decoder);
> +decoder->timer_id = g_timeout_add(time_diff,
> mjpeg_decoder_decode_frame, decoder);
> break;
> }
> 
> -SPICE_DEBUG("%s: rendering too late by %u ms (ts: %u,
> mmtime:
> %u), dropping ",
> -__FUNCTION__, time - op->multi_media_time,
> +SPICE_DEBUG("%s: rendering too late by %d ms (ts: %u,
> mmtime:
> %u), dropping ",
> +__FUNCTION__, -time_diff,
> op->multi_media_time, time);
> stream_dropped_frame_on_playback(decoder->base.stream);
> spice_msg_in_unref(frame_msg);
> @@ -249,7 +249,9 @@ static gboolean
> mjpeg_decoder_queue_frame(VideoDecoder
> *video_decoder,
> SpiceStreamDataHeader *last_op, 

Re: [Spice-devel] [PATCH 02/12] qxl-wddm-dod: Use rendering offload thread

[Christophe de Dinechin]

> On 21 Mar 2017, at 14:52, Christophe de Dinechin <cdupo...@redhat.com> wrote:
> 
>> 
>> On 21 Mar 2017, at 13:59, Yuri Benditovich <yuri.benditov...@daynix.com 
>> <mailto:yuri.benditov...@daynix.com>> wrote:
>> 
>> 
>> 
>> On Mon, Mar 20, 2017 at 2:08 PM, Frediano Ziglio <fzig...@redhat.com 
>> <mailto:fzig...@redhat.com>> wrote:
>> >
>> > Instead of sending drawable commands down from presentation
>> > callback, collect drawables objects and pass them to dedicated
>> > thread for processing. This reduce peak load of presentation
>> > callback.
>> >
>> > Signed-off-by: Javier Celaya <javier.cel...@flexvdi.com 
>> > <mailto:javier.cel...@flexvdi.com>>
>> > Signed-off-by: Yuri Benditovich <yuri.benditov...@daynix.com 
>> > <mailto:yuri.benditov...@daynix.com>>
>> > ---
>> >  qxldod/QxlDod.cpp | 43 +--
>> >  qxldod/QxlDod.h   |  4 ++--
>> >  2 files changed, 35 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/qxldod/QxlDod.cpp b/qxldod/QxlDod.cpp
>> > index b952bf9..01de9b3 100755
>> > --- a/qxldod/QxlDod.cpp
>> > +++ b/qxldod/QxlDod.cpp
>> > @@ -3794,11 +3794,20 @@ QxlDevice::ExecutePresentDisplayOnly(
>> >  SIZE_T sizeRects = NumDirtyRects*sizeof(RECT);
>> >  SIZE_T size = sizeof(DoPresentMemory) + sizeMoves + sizeRects;
>> >
>> > +QXLDrawable **pDrawables = reinterpret_cast(new
>> > (NonPagedPoolNx) BYTE[sizeof(QXLDrawable *)*(NumDirtyRects + NumMoves +
>> > 1)]);
>> 
>> here would be
>> 
>>   QXLDrawable **pDrawables = new (NonPagedPoolNx) QXLDrawable 
>> *[NumDirtyRects + NumMoves + 1];
>> 
>> is non paged memory needed? Both functions (producer and consumer) are in 
>> paged areas.
>> 
>> > +UINT nIndex = 0;
>> > +
>> > +if (!pDrawables)
>> > +{
>> > +return STATUS_NO_MEMORY;
>> > +}
>> > +
>> >  DoPresentMemory* ctx = reinterpret_cast<DoPresentMemory*>
>> >  (new (NonPagedPoolNx) BYTE[size]);
>> >
>> 
>>DoPresentMemory* ctx = new (NonPagedPoolNx) DoPresentMemory;
>> 
>> Current commit intentionally does not change this, to make clear what is 
>> changed.
> 
> Good.
> 
> If we use a non-paged placement new, shouldn’t we use a corresponding 
> placement delete?

Just checked by looking at the Microsoft sample code. They use plain delete. 
This still seems wrong to me. The underlying pool is not the same. It probably 
works because the pools share the same internal layout, so the same operator 
delete works in both cases.



> 
> 
>> Without changes in the code we can't just allocate less memory, as trailing 
>> RECT structures are used for
>> unneeded copy from parameters.
>> Removal of this completely unneeded 'ctx' is planned for further commits 
>> after all the HCK-related work is done.
> 
>>  
>> 
>> same comments as above
>> 
>> >  if (!ctx)
>> >  {
>> > +delete[] reinterpret_cast<BYTE*>(pDrawables);
>> 
>> delete[] pDrawables;
>> 
>> >  return STATUS_NO_MEMORY;
>> >  }
>> >
>> > @@ -3828,6 +3837,8 @@ QxlDevice::ExecutePresentDisplayOnly(
>> >  PMDL mdl = IoAllocateMdl((PVOID)SrcAddr, sizeToMap,  FALSE, FALSE,
>> >  NULL);
>> >  if(!mdl)
>> >  {
>> > +delete[] reinterpret_cast<BYTE*>(ctx);
>> > +delete[] reinterpret_cast<BYTE*>(pDrawables);
>> 
>> similar to above, in this case "delete ctx;"
>> 
>> >  return STATUS_INSUFFICIENT_RESOURCES;
>> >  }
>> >
>> > @@ -3844,6 +3855,8 @@ QxlDevice::ExecutePresentDisplayOnly(
>> >  {
>> >  Status = GetExceptionCode();
>> >  IoFreeMdl(mdl);
>> > +delete[] reinterpret_cast<BYTE*>(ctx);
>> > +delete[] reinterpret_cast<BYTE*>(pDrawables);
>> 
>> ditto
>> 
>> >  return Status;
>> >  }
>> >
>> > @@ -3857,6 +3870,8 @@ QxlDevice::ExecutePresentDisplayOnly(
>> >  Status = STATUS_INSUFFICIENT_RESOURCES;
>> >  MmUnlockPages(mdl);
>> >  IoFreeMdl(mdl);
>> > +delet

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

[Christophe de Dinechin]

> On 6 Mar 2017, at 11:42, Frediano Ziglio  wrote:
> 
> On 3 Mar 2017, at 13:10, Marc-André Lureau  > wrote:
> 
> Hi
> 
> - Original Message -
> 
> Hi
> 
> - Original Message -
> 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 
> ;
> - https://bugzilla.redhat.com/show_bug.cgi?id=1294564 
>  (probably).
> 
> 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.
> 
> How much extra CPU usage does this take? in non-degenerate case and
> degenerated case.
> 
> I would suggest to fix the root cause: that X splits and copy large region
> update.
> 
> The solution I proposed:
> https://lists.freedesktop.org/archives/mesa-dev/2015-June/085860.html 
> 
> 
> Not only it doesn't require extra work on Spice side, but it also improves
> guest CPU usage by avoiding large memcpy (fullscreen video can be very
> heavy)
> 
> 
> Fine with it.
> Can you do it?
> 
> 
> I may eventually do it, but it's not in my priorities.
> 
> The last update from me was "[PATCHv2 0/9] drisw/glx: use XShm if possible" 
> (6/15/15).
> 
> Adam Jackson was supposed to review/take it. I don't know if anything 
> happened since.
> 
> Ajax, any update? could you look at it? I see the bug is assigned to Dave 
> (rhbz#1030024)
> 
> Anyone willing to take it?
> 
> Willing I am. Able I don’t know ;-) If I’m stumped, I know who to call for 
> help.
> 
> Christophe
> Would be great to have this fixed instead of a workaround!
> On the other way the only thing we could do is updating the patch, testing 
> and pushing Mesa
> to merge it.
> Could we actually just accept the patch downstream, at least for 7.4 ?
> 
> Posted a message in https://bugzilla.redhat.com/show_bug.cgi?id=1030024 
>  to ask
> for some commitment. Seems that the bug was stuck since an year.

I adjusted the patch for the then-current version of mesa. See 
https://github.com/c3d/mesa/commit/6709e8c3bd8af5df9f748ee3449598aa1787fe51. 
Updated rhbz1030024.

Christophe


> 
> Frediano
> 
> ___
> 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] [PATCH v2 12/12] qxl-wddm-dod: Non-forced memory allocations with VSync

[Christophe de Dinechin]

> On 1 Apr 2017, at 18:40, Yuri Benditovich  wrote:
> 
> From: "yuri.benditov...@daynix.com" 
> 
> In case of VSync is active allocate bitmaps for drawable objects
> using non-forced requests.

The relation with VSync being active is not obvious from this patch alone. From 
your earlier patch, I’d explain using something derived from the following tex, 
i.e explaining when it happens rather than “VSync is active"t:

when forced memory allocation used, but the driver already received
stop command and waits for thread termination. Note that in case
the VSync control is enabled stop command may happen even after the video
subsystem executes switch to VGA mode. In such case QEMU will not return
previously allocated objects (assuming the QXL driver already disabled
and ignoring callbacks from Spice server in VGA mode).

Christophe

> If immediate allocation is not possible,
> place entire bitmap into memory chunk allocated from the OS.
> If bitmap is allocated from device memory, but one of later
> chunks can't be allocated, allocate this and further chunks from
> OS memory. All these 'delayed' allocations placed into linked list
> which root entry is part of QXLOutput structure.
> From separate thread, before sending drawable objects down, review
> the list of delayed chunks and allocate device memory (forced) to
> all of them.
> The cost of solution is 2 pointers added to each drawable or cursor object.
> Cursor commands currently do not use them; in future we have an option
> to offload also cursor commands.
> 
> Signed-off-by: Yuri Benditovich 
> ---
> qxldod/QxlDod.cpp | 107 ++
> qxldod/QxlDod.h   |   3 ++
> 2 files changed, 102 insertions(+), 8 deletions(-)
> 
> diff --git a/qxldod/QxlDod.cpp b/qxldod/QxlDod.cpp
> index a807396..5a4e17d 100755
> --- a/qxldod/QxlDod.cpp
> +++ b/qxldod/QxlDod.cpp
> @@ -4213,6 +4213,13 @@ void QxlDevice::DrawableAddRes(QXLDrawable *drawable, 
> Resource *res)
>AddRes(output, res);
> }
> 
> +static FORCEINLINE PLIST_ENTRY DelayedList(QXLDrawable *pd)
> +{
> +QXLOutput *output;
> +output = (QXLOutput *)((UINT8 *)pd - sizeof(QXLOutput));
> +return >list;
> +}
> +
> void QxlDevice::CursorCmdAddRes(QXLCursorCmd *cmd, Resource *res)
> {
>PAGED_CODE();
> @@ -4320,6 +4327,7 @@ QXLDrawable *QxlDevice::Drawable(UINT8 type, CONST RECT 
> *area, CONST RECT *clip,
>drawable->surfaces_dest[1] = - 1;
>drawable->surfaces_dest[2] = -1;
>CopyRect(>bbox, area);
> +InitializeListHead(DelayedList(drawable));
> 
>if (!SetClip(clip, drawable)) {
>DbgPrint(TRACE_LEVEL_VERBOSE, ("%s: set clip failed\n", __FUNCTION__));
> @@ -4414,7 +4422,7 @@ BOOLEAN QxlDevice::AttachNewBitmap(QXLDrawable 
> *drawable, UINT8 *src, UINT8 *src
>Resource *image_res;
>InternalImage *internal;
>QXLDataChunk *chunk;
> -PLIST_ENTRY pDelayedList = NULL;
> +PLIST_ENTRY pDelayedList = bForce ? NULL : DelayedList(drawable);
>UINT8* dest, *dest_end;
> 
>height = drawable->u.copy.src_area.bottom;
> @@ -4483,9 +4491,12 @@ BOOLEAN QxlDevice::AttachNewBitmap(QXLDrawable 
> *drawable, UINT8 *src, UINT8 *src
>}
> 
>for (; src != src_end; src -= pitch, alloc_size -= line_size) {
> -BOOLEAN b = PutBytesAlign(, , _end, src, line_size, 
> alloc_size, pDelayedList);
> -if (!b) {
> -DbgPrint(TRACE_LEVEL_WARNING, ("%s: aborting copy of lines\n", 
> __FUNCTION__));
> +if (!PutBytesAlign(, , _end, src, line_size, 
> alloc_size, pDelayedList)) {
> +if (pitch < 0 && bForce) {
> +DbgPrint(TRACE_LEVEL_WARNING, ("%s: aborting copy of lines 
> (forced)\n", __FUNCTION__));
> +} else {
> +DbgPrint(TRACE_LEVEL_WARNING, ("%s: unexpected aborting copy 
> of lines (force %d, pitch %d)\n", __FUNCTION__, bForce, pitch));
> +}
>return FALSE;
>}
>}
> @@ -4540,7 +4551,13 @@ QXLDrawable *QxlDevice::PrepareBltBits (
>UINT8* src_end = src - pSrc->Pitch;
>src += pSrc->Pitch * (height - 1);
> 
> -if (!AttachNewBitmap(drawable, src, src_end, (INT)pSrc->Pitch, TRUE)) {
> +if (!AttachNewBitmap(drawable, src, src_end, (INT)pSrc->Pitch, 
> !g_bSupportVSync)) {
> +PLIST_ENTRY pDelayedList = DelayedList(drawable);
> +// if some delayed chunks were allocated, free them
> +while (!IsListEmpty(pDelayedList)) {
> +QXL_DELAYED_CHUNK *pdc = (QXL_DELAYED_CHUNK 
> *)RemoveHeadList(pDelayedList);
> +delete[] reinterpret_cast(pdc);
> +}
>ReleaseOutput(drawable->release_info.id);
>drawable = NULL;
>}
> @@ -5175,11 +5192,75 @@ void QxlDevice::StopPresentThread()
>}
> }
> 
> +QXLDataChunk *QxlDevice::MakeChunk(QXL_DELAYED_CHUNK *pdc)
> +{
> +PAGED_CODE();
> +QXLDataChunk *chunk = (QXLDataChunk *)AllocMem(MSPACE_TYPE_VRAM, 
> 

Re: [Spice-devel] [PATCH spice-server] test-leaks: Checks some leaks using TLS

[Christophe de Dinechin]

[Resend, apparently stayed in my outbox for a few days]
> On 7 Mar 2017, at 17:56, Frediano Ziglio  wrote:
> 
> Verify stuff are freed correctly (like TLS context).
> The different PKI file required are generated with
> base values (localhost and rsa 1024).

I went back into the history. I see that the test itself does not check for 
leaks, but that you need to run it with an external leak checker, right?

Would it be possible to add a comment in test-leaks.c? Maybe a command with an 
example of leak checker that works for you?

Thanks
Christophe

> 
> Signed-off-by: Frediano Ziglio 
> ---
> server/tests/Makefile.am |  1 +
> server/tests/pki/ca-cert.pem | 16 
> server/tests/pki/server-cert.pem | 18 ++
> server/tests/pki/server-key.pem  | 15 +++
> server/tests/test-leaks.c|  9 +
> 5 files changed, 59 insertions(+)
> create mode 100644 server/tests/pki/ca-cert.pem
> create mode 100644 server/tests/pki/server-cert.pem
> create mode 100644 server/tests/pki/server-key.pem
> 
> diff --git a/server/tests/Makefile.am b/server/tests/Makefile.am
> index db23177..3f61faa 100644
> --- a/server/tests/Makefile.am
> +++ b/server/tests/Makefile.am
> @@ -1,6 +1,7 @@
> NULL =
> 
> AM_CPPFLAGS = \
> + -DSPICE_TOP_SRCDIR=\"$(abs_top_srcdir)\"\
>   -I$(top_srcdir) \
>   -I$(top_srcdir)/server  \
>   -I$(top_builddir)/server\
> diff --git a/server/tests/pki/ca-cert.pem b/server/tests/pki/ca-cert.pem
> new file mode 100644
> index 000..a2068ce
> --- /dev/null
> +++ b/server/tests/pki/ca-cert.pem
> @@ -0,0 +1,16 @@
> +-BEGIN CERTIFICATE-
> +MIICkTCCAfoCCQCRTWOpSfdW3jANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMC
> +VUsxCzAJBgNVBAgMAkNBMRIwEAYDVQQHDAlDYW1icmlkZ2UxEzARBgNVBAoMCkV4
> +YW1wbGUgQ28xEDAOBgNVBAsMB3RlY2hvcHMxEzARBgNVBAMMClRlc3RpbmcgQ0Ex
> +IDAeBgkqhkiG9w0BCQEWEWNlcnRzQGV4YW1wbGUuY29tMB4XDTE3MDMwNTE1NTE0
> +NFoXDTQ0MDcyMDE1NTE0NFowgYwxCzAJBgNVBAYTAlVLMQswCQYDVQQIDAJDQTES
> +MBAGA1UEBwwJQ2FtYnJpZGdlMRMwEQYDVQQKDApFeGFtcGxlIENvMRAwDgYDVQQL
> +DAd0ZWNob3BzMRMwEQYDVQQDDApUZXN0aW5nIENBMSAwHgYJKoZIhvcNAQkBFhFj
> +ZXJ0c0BleGFtcGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA8ZzC
> +wYryCMwWSPJMrFCDn73+twpMfpW4J2DR+HTT3nBcjW5gIfZ6fUZWn0wovfeDqMiU
> +1cKtJY45U14kwvZDuVTIZtpvqWAVX4t+KYN1MQuWuQsN7f9q6VEi0hyI9CiTi8PY
> +tW2r0d/1SDdV4oKQBVwv15/zFJCETM38DPAxnYkCAwEAATANBgkqhkiG9w0BAQsF
> +AAOBgQBw8BUg4l0EuZxy2F6z/wG7VSruHQupFexsJpIsr268wotpYnvAigXYCsh6
> +PB042JHhBZs317GolUEExxWiLMjKcpggYYHX4WpA9nuN/QpK+1CrUmlILIrgTScY
> +1Z7U7bRko3gBuF5dd7DneZQZGWBfpaqDbeufs1ZDTp5cIV8K5A==
> +-END CERTIFICATE-
> diff --git a/server/tests/pki/server-cert.pem 
> b/server/tests/pki/server-cert.pem
> new file mode 100644
> index 000..cc90111
> --- /dev/null
> +++ b/server/tests/pki/server-cert.pem
> @@ -0,0 +1,18 @@
> +-BEGIN CERTIFICATE-
> +MIIC6DCCAlGgAwIBAgIJAKa/0Imqt34SMA0GCSqGSIb3DQEBCwUAMIGMMQswCQYD
> +VQQGEwJVSzELMAkGA1UECAwCQ0ExEjAQBgNVBAcMCUNhbWJyaWRnZTETMBEGA1UE
> +CgwKRXhhbXBsZSBDbzEQMA4GA1UECwwHdGVjaG9wczETMBEGA1UEAwwKVGVzdGlu
> +ZyBDQTEgMB4GCSqGSIb3DQEJARYRY2VydHNAZXhhbXBsZS5jb20wHhcNMTcwMzA1
> +MTU1MTQ0WhcNMTkxMTI5MTU1MTQ0WjCBizELMAkGA1UEBhMCVUsxCzAJBgNVBAgM
> +AkNBMRIwEAYDVQQHDAlDYW1icmlkZ2UxETAPBgNVBAoMCEZyZWRpYW5vMRAwDgYD
> +VQQLDAd0ZWNob3BzMRQwEgYDVQQDDAtUZXN0IFNlcnZlcjEgMB4GCSqGSIb3DQEJ
> +ARYRY2VydHNAZXhhbXBsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
> +AL7GOdOpqx26TSA/lQCOAcPGZ6mWhCtRUVaWXn+AKdmyNQ477ioSY2sSvTyYAodO
> +hOHJo9UXQJ9Q526A4rGizCFZ4AdTX14j0Hf1V3Qx2yftLNKkjUol7ZI693FLltL0
> +jiPStcB4YQbbtfywUIp9Qv9QP56Fym5DljaolGvBJ7wrAgMBAAGjUTBPMAwGA1Ud
> +EwEB/wQCMAAwCwYDVR0PBAQDAgXgMDIGA1UdEQQrMCmCCWxvY2FsaG9zdIcEfwAA
> +AYcQAYcEwKh/ATANBgkqhkiG9w0BAQsFAAOBgQA0Gtoc
> +KKpnEsVxg89MlhFJw/H8DirfVTew2fXq65POBb42aku8yfBRwvhu+EkNO9qqDwGt
> +NGBB/uJ2f4cpWX1T3rXLlTU9vX8+9sIHU7jAVz1Kkev/R2iXQBDM9lDMOde8fh7P
> +x6vmcnKAGyQN4O1vOIl07K90dpZJ+QLL5SbhDA==
> +-END CERTIFICATE-
> diff --git a/server/tests/pki/server-key.pem b/server/tests/pki/server-key.pem
> new file mode 100644
> index 000..099e7e0
> --- /dev/null
> +++ b/server/tests/pki/server-key.pem
> @@ -0,0 +1,15 @@
> +-BEGIN RSA PRIVATE KEY-
> +MIICXAIBAAKBgQC+xjnTqasduk0gP5UAjgHDxmeploQrUVFWll5/gCnZsjUOO+4q
> +EmNrEr08mAKHToThyaPVF0CfUOdugOKxoswhWeAHU19eI9B39Vd0Mdsn7SzSpI1K
> +Je2SOvdxS5bS9I4j0rXAeGEG27X8sFCKfUL/UD+ehcpuQ5Y2qJRrwSe8KwIDAQAB
> +AoGAbC0nGTi6iS7dEQ48xYXAxmy411c8NvvzbW/ywcXA9Wqx3xJoqH6o1UxY9gUU
> +WflSLF4Ugn6e7DgKI4T+BtBTgxMLgmPxn3pjCXLUlrh7F2Zw8YSVaEARc863kmK6
> +BZElhmzZ4UzT5WCQhKMnxeCOGaoUuv6+0/epKc4vCCpU2bECQQDl1XtB9x0fwNMu
> +o+PFAE71AfXjFLI8KSe1lp43zOXRzobOL9noYFyVgoaAoGguAAmz69w412LH9Hac
> +aigGaYzlAkEA1H5Z3dL6hCkwNJ5A4VhVfmnFT0bSwrI+kc9QBgWw7wixNoF6HWSb
> +FpYu3MIiVby1tZQiR0KwENWj1e5YACWjzwJBAJbkkNbfOZTGUR/246xMJop+7gNX
> +bClJT9PNfjTeZihX8nNeQS9qTH6wQkQijCNfTP9+I4iCCE2E93Z7z6leFO0CQC3r
> 

Re: [Spice-devel] [RFC] Spice channels compression

[Christophe de Dinechin]

> On 7 Mar 2017, at 16:37, Frediano Ziglio  > wrote:
> 
>>> 
>>> 
>>> Hi Snir,
>>> 
>>> Regarding compression and another topic recently evoked, endianness, I
>>> wonder
>>> if encoding using LEB128 had been discussed?
>>> 
>>> LEB128 encodes any value below 128 as 1 bytes, any value below ~16000 as 2
>>> bytes, and so on. It is size and endianness independent. This means that we
>>> can extend a field from uint16 to uint32 without protocol incompatibility.
>>> It is much less computationally expensive than full compression. I think it
>>> would apply very well to a lot of our meta-data, but would be less
>>> effective
>>> than regular compression algorithms with image data proper. So it’s
>>> addressing another part of the problem.
>>> 
>>> I have no real feeling yet for how important that other part is in the
>>> streams, but my guts tell me “probably not much” (i.e. I expect much more
>>> image data than meta-data). Still, it might be worth trying. But it’s
>>> probably not just a capability: if we want to encode most fields that way,
>>> this means a protocol bump. Not sure it’s worth it.
>>> 
>>> The code to encode and decode is really short. Here is an example for
>>> writing:
>>> https://github.com/c3d/XL-programming-language/blob/master/xlr/serializer.cpp#L219
>>>  
>>> .
>>> Here is an example for reading:
>>> https://github.com/c3d/XL-programming-language/blob/master/xlr/serializer.cpp#L406
>>>  
>>> .
>>> 
>>> 
>>> Christophe
>>> 
>> 
>> Maybe helpful however Snir is working more on payload compression than
>> structured data so the gain would be not great (he use few fields).
>> However maybe some statistics can be done. Our "mini" header is 16 bit
>> type and 32 bit length. For instance you can add some statistics recording
>> - number of messages
>> - total messages payload
>> - total LEB128 encoded header (the not encoded is number of messages * 6).
>> If you want also to try compressing (or doing statistics on) fields you
>> could add some code to the code generated by python scripts in spice-common.
>> 
> 
> I instrumented a bit the code to understand how this LEB128 could affect
> fields (not the header).
> The algorithm remove about 50-60% of field data however this affect the
> total bandwidth utilization by about 0.2-0.4% mainly due to the display
> channel. Maybe for other channels we could have better gain.

Thanks for testing this. I’m not too surprised by them given the nature of the 
data.

Christophe

> 
> Frediano
> 
>> 
 On 2 Mar 2017, at 17:53, Snir Sheriber > wrote:
 
 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
 
> ___
> 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

[Spice-devel] Is it possible to build without vala?

[Christophe de Dinechin]

In the configure.ac, the default for vala is “no”. But if I build without it, I 
get:

make[4]: Entering directory `/Users/ddd/Work/spice/spice-gtk/src/controller'

  *** Error: missing valac!
  *** You must run autogen.sh or configure --enable-vala

Is it possible to build spice-gtk without valac? If not, should I add this as a 
requirement and make it a default in configure.ac? Or is the controller 
optional somehow?


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

Re: [Spice-devel] Is it possible to build without vala?

[Christophe de Dinechin]

> On 8 Mar 2017, at 19:17, Marc-André Lureau  wrote:
> 
> Hi
> 
> - Original Message -
>> In the configure.ac, the default for vala is “no”. But if I build without it,
>> I get:
>> 
>> make[4]: Entering directory `/Users/ddd/Work/spice/spice-gtk/src/controller'
>> 
>>  *** Error: missing valac!
>>  *** You must run autogen.sh or configure --enable-vala
>> 
>> Is it possible to build spice-gtk without valac? If not, should I add this as
>> a requirement and make it a default in configure.ac? Or is the controller
>> optional somehow?
> 
> --disable-vala --disable-controller should do

Meaning obviously the controller is optional. What do I lose if I disable it?

I assume this means configure should enforce this dependency, right?

> 
>> 
>> 
>> Thanks
>> Christophe
>> ___
>> 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

[Spice-devel] Alignment of data within spice packets

[Christophe de Dinechin]

I have several errors like this:

spice-channel.c:1923:12: error: cast from 'uint8_t *' (aka 'unsigned char *') to
  'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to
  4 [-Werror,-Wcast-align]
  ...(uint32_t *)((uint8_t *)c->peer_msg + 
GUINT32_FROM_LE(c->peer_msg->caps_offset));
 
^~~~

Is there any guarantee that the result pointer will be 32-bit aligned? In other 
words, is it guaranteed that the c->peer_msg->caps_offset will be a multiple of 
4? I don’t see this written in the spec.

Based on the answer, the correct fix is:

- If aligned, to cast to a uint32_t * in a way that disables the warning

- If misaligned, to replaced *p with a read operation that is safe when 
mis-aligned (OS dependent I guess)


Thanks
Christophe

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

Re: [Spice-devel] Alignment of data within spice packets

[Christophe de Dinechin]

> On 8 Mar 2017, at 22:16, Victor Toso <li...@victortoso.com> wrote:
> 
> Hi,
> 
> On Wed, Mar 08, 2017 at 07:21:15PM +0100, Christophe de Dinechin wrote:
>> I have several errors like this:
>> 
>> spice-channel.c:1923:12: error: cast from 'uint8_t *' (aka 'unsigned char 
>> *') to
>>  'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 
>> to
>>  4 [-Werror,-Wcast-align]
>>  ...(uint32_t *)((uint8_t *)c->peer_msg + 
>> GUINT32_FROM_LE(c->peer_msg->caps_offset));
>> 
>> ^~~~
>> 
>> Is there any guarantee that the result pointer will be 32-bit aligned?
>> In other words, is it guaranteed that the c->peer_msg->caps_offset
>> will be a multiple of 4? I don’t see this written in the spec.
>> 
>> Based on the answer, the correct fix is:
>> 
>> - If aligned, to cast to a uint32_t * in a way that disables the warning
>> 
>> - If misaligned, to replaced *p with a read operation that is safe when 
>> mis-aligned (OS dependent I guess)
> 
> Yes, we should check case-by-case. I started doing some work around this
> (nearly one and half year ago already!) but I got stuck on explaining
> the rationale for each cast which would avoid the warnings.
> 
> You can see the comments and suggestions at the time are in the
> following thread:
> 
> https://lists.freedesktop.org/archives/spice-devel/2015-August/021535.html 
> <https://lists.freedesktop.org/archives/spice-devel/2015-August/021535.html>

Ach, I see you used SPICE_ALIGNED_CAST and SPICE_UNALIGNED_CAST. I used 
SPICE_REALIGN_CAST :-(

Will try to integrate your patches, thanks.

> 
> Cheers,
>toso
>> 
>> 
>> Thanks
>> Christophe
>> 
>> ___
>> Spice-devel mailing list
>> Spice-devel@lists.freedesktop.org <mailto:Spice-devel@lists.freedesktop.org>
>> https://lists.freedesktop.org/mailman/listinfo/spice-devel 
>> <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] [RFC] Spice channels compression

[Christophe de Dinechin]

Hi Snir,

Regarding compression and another topic recently evoked, endianness, I wonder 
if encoding using LEB128 had been discussed?

LEB128 encodes any value below 128 as 1 bytes, any value below ~16000 as 2 
bytes, and so on. It is size and endianness independent. This means that we can 
extend a field from uint16 to uint32 without protocol incompatibility. It is 
much less computationally expensive than full compression. I think it would 
apply very well to a lot of our meta-data, but would be less effective than 
regular compression algorithms with image data proper. So it’s addressing 
another part of the problem.

I have no real feeling yet for how important that other part is in the streams, 
but my guts tell me “probably not much” (i.e. I expect much more image data 
than meta-data). Still, it might be worth trying. But it’s probably not just a 
capability: if we want to encode most fields that way, this means a protocol 
bump. Not sure it’s worth it.

The code to encode and decode is really short. Here is an example for writing: 
https://github.com/c3d/XL-programming-language/blob/master/xlr/serializer.cpp#L219.
 Here is an example for reading: 
https://github.com/c3d/XL-programming-language/blob/master/xlr/serializer.cpp#L406.


Christophe

> On 2 Mar 2017, at 17:53, Snir Sheriber  wrote:
> 
> 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

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

[Spice-devel] Use of sized ints

[Christophe de Dinechin]

We have recently discussed the use of the bool type. What about sized int 
types? What is the policy here?

Notably, on a part of the code I’m presently working on, I saw that surface_id 
could be either an int or an uint32_t. There is apparently no clear winner:

$ git grep "int.*surface_id" | wc
 141 659   12350
$ git grep "uint32.*surface_id" | wc
  89 4348182

So this means roughly 63% uint32 and 36% “other ints”…

In your opinion, for new code, should I use unsigned, int or uint32 for a 
surface_id parameter? (My personal vote would be unsigned)


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

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

[Christophe de Dinechin]

> On 3 Mar 2017, at 13:10, Marc-André Lureau  wrote:
> 
> Hi
> 
> - Original Message -
>>> 
>>> Hi
>>> 
>>> - Original Message -
 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;
 - https://bugzilla.redhat.com/show_bug.cgi?id=1294564 (probably).
 
 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.
>>> 
>>> How much extra CPU usage does this take? in non-degenerate case and
>>> degenerated case.
>>> 
>>> I would suggest to fix the root cause: that X splits and copy large region
>>> update.
>>> 
>>> The solution I proposed:
>>> https://lists.freedesktop.org/archives/mesa-dev/2015-June/085860.html
>>> 
>>> Not only it doesn't require extra work on Spice side, but it also improves
>>> guest CPU usage by avoiding large memcpy (fullscreen video can be very
>>> heavy)
>>> 
>> 
>> Fine with it.
>> Can you do it?
>> 
> 
> I may eventually do it, but it's not in my priorities.
> 
> The last update from me was "[PATCHv2 0/9] drisw/glx: use XShm if possible" 
> (6/15/15).
> 
> Adam Jackson was supposed to review/take it. I don't know if anything 
> happened since.
> 
> Ajax, any update? could you look at it? I see the bug is assigned to Dave 
> (rhbz#1030024)
> 
> Anyone willing to take it?

Willing I am. Able I don’t know ;-) If I’m stumped, I know who to call for help.

Christophe

> 
> thanks
> ___
> 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] Use of sized ints

[Christophe de Dinechin]

> On 3 Mar 2017, at 13:17, Frediano Ziglio  wrote:
> 
>> 
>> We have recently discussed the use of the bool type. What about sized int
>> types? What is the policy here?
>> 
>> Notably, on a part of the code I’m presently working on, I saw that
>> surface_id could be either an int or an uint32_t. There is apparently no
>> clear winner:
>> 
>> $ git grep "int.*surface_id" | wc
>> 141 659   12350
>> $ git grep "uint32.*surface_id" | wc
>>  89 4348182
>> 
>> So this means roughly 63% uint32 and 36% “other ints”…
>> 
>> In your opinion, for new code, should I use unsigned, int or uint32 for a
>> surface_id parameter? (My personal vote would be unsigned)
>> 
>> 
>> Christophe
> 
> int16 !

Actually, the reason I vote for ‘unsigned’ is to use a “base” machine type. I 
think for parameters and local variables (i.e. stuff that ideally lives in 
registers and not memory) it’s better.

> 
> :-)
> 
> I think on the network they are sent using uint32 however in some code -1
> (so basically 0x) is assumed the invalid standard value.
> Other invalid values (<0 or >maximum) are discarded (the entire command
> is discarded). The maximum is 1000 so in some way int16 would even make sense!

Yes, but if you use int16 as an argument, you force the machine to compute on 
16 bits. On x86, it’s relatively OK, there are 16-bit opcodes for everything 
since it started as a 16-bit ISA. But on ARM, PPC or other machines, the 
compiler may end up emitting additional code (things like “zero extend” or 
“sign extend” instructions) to make sure you only observe 16-bit values. So 
int16 makes sense for a struct field or a pointer type, rarely for parameters 
or locals. It does not hurt that much either, though.

Christophe

> 
> Frediano
> ___
> 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] [PATCH v3 1/2] display-channel: Join drawables to improve rhel7 behaviour

[Christophe de Dinechin]

> On 3 Mar 2017, at 12:46, 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 | 220 +++-
> server/red-parse-qxl.h   |   1 +-
> server/red-worker.c  |  14 +-
> 4 files changed, 230 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 67a77ef..e95741f 100644
> --- a/server/display-channel.c
> +++ b/server/display-channel.c
> @@ -78,6 +78,8 @@ display_channel_finalize(GObject *object)
> {
>DisplayChannel *self = DISPLAY_CHANNEL(object);
> 
> +red_drawable_unref(self->priv->joinable_drawable);
> +
>display_channel_destroy_surfaces(self);
>image_cache_reset(>priv->image_cache);
>monitors_config_unref(self->priv->monitors_config);
> @@ -1176,8 +1178,190 @@ 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 is a simple copy that can
> + * possibly be joined to next one.
> + * 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.
> + * One example is RHEL 7.
> + * Some of the check in this function are just to check that the
> + * operation is a opaque bitmap copy operations, some other just
> + * avoid to make the joining code more complicated just to support
> + * unseen commands.
> + */
> +static bool red_drawable_joinable(const RedDrawable *drawable)
> +{
> +// These 3 initial tests are arranged to minimize checks as
> +// they are arranged from more probable to less probable

Any reason not to group all the tests with || ?

> +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;
> +}
> +// Never seen, avoid to support during join
> +if (drawable->self_bitmap) {
> +return false;
> +}
> +// Consistency, a copy should not have dependencies
> +if (drawable->surface_deps[0] != -1 ||
> +drawable->surface_deps[1] != -1 ||
> +drawable->surface_deps[2] != -1) {
> +return false;
> +}
> +
> +const SpiceCopy *copy = >u.copy;
> +// We need a bitmap
> +if (copy->src_bitmap == NULL) {
> +return false;
> +}
> +if (copy->rop_descriptor != SPICE_ROPD_OP_PUT) {
> +return false;
> +}
> +// Never seen, avoid to support during join
> +if (copy->mask.bitmap != NULL) {
> +return false;
> +}
> +
> +// Limit image support to 32bit bitmap
> +const SpiceImage *image = copy->src_bitmap;

For my education: I thought the style was to declare variables ahead of time 
(which I personally don’t like much). But I prefer the way you wrote it.

> +if (image->descriptor.type != SPICE_IMAGE_TYPE_BITMAP) {
> +return false;
> +}
> +const SpiceBitmap *bitmap = >u.bitmap;
> +if (bitmap->format != SPICE_BITMAP_FMT_RGBA && bitmap->format != 
> SPICE_BITMAP_FMT_32BIT) {
> +return false;
> +}

If you restrict to 32-bit bitmaps, it might be worth adding to the comment, and 
explaining why. Is it “never seen”, “can’t do” or “don’t want to do”?

> +// Never seen anything else, avoid to support during join.
> +// We could not easily join bitmap with different orientations
> +if (bitmap->flags != SPICE_BITMAP_FLAGS_TOP_DOWN) {
> +return false;
> +}
> +// Consistency, a 32bit image have no reason to have a palette
> +if (bitmap->palette != NULL) {
> +return false;
> +}
> +if (bitmap->data == NULL) {
> +return false;
> +}
> +// 

Re: [Spice-devel] [PATCH spice-protocol 2/2] agent: Add macro for clearing capability

[Christophe de Dinechin]

> On 28 Feb 2017, at 18:26, Frediano Ziglio  > wrote:
> 
>> 
>> On Tue, 2017-02-28 at 09:29 -0500, Frediano Ziglio wrote:
 
 Related:
 https://bugzilla.redhat.com/show_bug.cgi?id=1373725 
 
 ---
  spice/vd_agent.h | 3 +++
  1 file changed, 3 insertions(+)
 
 diff --git a/spice/vd_agent.h b/spice/vd_agent.h
 index ac22498..3b1f183 100644
 --- a/spice/vd_agent.h
 +++ b/spice/vd_agent.h
 @@ -269,6 +269,9 @@ typedef struct SPICE_ATTR_PACKED
 VDAgentAnnounceCapabilities {
  #define VD_AGENT_SET_CAPABILITY(caps, index) \
  { (caps)[(index) / 32] |= (1 << ((index) % 32)); }
  
 +#define VD_AGENT_CLEAR_CAPABILITY(caps, index) \
 +{ (caps)[(index) / 32] &= ~(1 << ((index) % 32)); }
 +
  #include 
  
  #endif /* _H_VD_AGENT */
>>> 
>>> I would say
>>> 
>>> Acked-by: Frediano Ziglio >
>>> 
>>> Honestly I don't think should be a 2/2, just a separate patch.
>>> 
>>> The related bug comment for a so generic patch looks a bit weird.
>> true, sorry, it is a leftover
>>> 
>>> Would be sensible to have a static inline function instead of
>>> a macro?
>> 
>> I did it as a complement to VD_AGENT_SET_CAPABILITY. Do you prefer a
>> function because of the type check ? I don't mind adding it, but I'd
>> keep something like:
>> 
>> static inline vd_agent_clear_capability(uint32_t *caps, uint32_t
>> index);
>> #define VD_AGENT_CLEAR_CAPABILITY vd_agent_set_capability
>> 
>> 
> 
> For me make sense. Let's see what other people think (if they prefer
> same style).
> 
> About capabilities and how to save. Currently the code uses little
> endian but as we are moving to support also big endian platforms
> we are adding code to swap the uint32_t. If we assume little
> endian these expression produce the same results:
> 
>   uint32_t *caps;
>   ...
>   caps[i / 32] |= 1 << (i % 32);
> 
>   uint32_t *caps;
>   ...
>   ((uint8_t*)caps)[i / 8] |= 1 << (i % 8);
> 
> But this last one does not require to swap to/from network in
> case of big endian.
> Could we use a different structure to store capabilities
> to avoiding swapping the array?
> Would make code to support big endian easier.

I vote for the uint8_t version. There is no gain that I know of 
performance-wise with the uint32_t version.

Christophe


> 
> Frediano
> ___
> 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] [PATCH spice] gl: fix client mouse mode

[Christophe de Dinechin]

> On 30 Jan 2017, at 13:50, marcandre.lur...@redhat.com wrote:
> 
> From: Marc-André Lureau 
> 
> Since 2.8, QEMU now longer creates QXL primary surfaces when using

Typo, “no longer"

> GL. This change broke client-side mouse mode, because Spice server
> relies on primary surface conditions.
> 
> When GL is enabled, use GL scanout informations, similar to what
> red_qxl_get_allow_client_mouse() is doing. The main difference is that
> the GL surface doesn't have mouse_mode attached (what for?).
> 
> NB: this code looks like it handles only first QXL instance only, and
> uses the whole scanout/surface size for the input table size, perhaps
> monitor-configs would be a better choice.
> 
> Signed-off-by: Marc-André Lureau 
> ---
> server/red-qxl.c | 2 ++
> server/reds.c| 8 +++-
> 2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/server/red-qxl.c b/server/red-qxl.c
> index b6b3770b..ba7b641a 100644
> --- a/server/red-qxl.c
> +++ b/server/red-qxl.c
> @@ -897,6 +897,8 @@ void spice_qxl_gl_scanout(QXLInstance *qxl,
> /* FIXME: find a way to coallesce all pending SCANOUTs */
> dispatcher_send_message(qxl_state->dispatcher,
> RED_WORKER_MESSAGE_GL_SCANOUT, );
> +
> +reds_update_client_mouse_allowed(qxl_state->reds);
> }
> 
> SPICE_GNUC_VISIBLE
> diff --git a/server/reds.c b/server/reds.c
> index 40c94851..a89c5e90 100644
> --- a/server/reds.c
> +++ b/server/reds.c
> @@ -4256,10 +4256,16 @@ void reds_update_client_mouse_allowed(RedsState *reds)
> if (num_active_workers > 0) {
> GListIter it;
> QXLInstance *qxl;
> +SpiceMsgDisplayGlScanoutUnix *gl;
> 
> allow_now = TRUE;
> FOREACH_QXL_INSTANCE(reds, it, qxl) {
> -if (red_qxl_get_primary_active(qxl)) {
> +if ((gl = red_qxl_get_gl_scanout(qxl))) {
> +x_res = gl->width;
> +y_res = gl->height;
> +red_qxl_put_gl_scanout(qxl, gl);
> +break;
> +} else if (red_qxl_get_primary_active(qxl)) {
> allow_now = red_qxl_get_allow_client_mouse(qxl, _res, 
> _res);
> break;
> }
> -- 
> 2.11.0.295.gd7dffce1c.dirty
> 
> ___
> 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] Survey of repository preferences

[Christophe de Dinechin]

> On 28 Jul 2017, at 12:10, Pavel Grunt <pgr...@redhat.com> wrote:

> 
> Hi,
> 
> On Fri, 2017-07-28 at 09:15 +0200, Christophe de Dinechin wrote:
>>> On 27 Jul 2017, at 17:07, Marc-André Lureau <marcandre.lur...@redhat.com>
>>> wrote:
>>> 
>>> Hi
>>> 
>>> - Original Message -
>>>>> I think we should rather find a consensus on the mailing list rather
>>>>> than
>>>>> avoiding the discussion.
>>>> 
>>>> “Avoiding the discussion" sounds like a cheap and unjustified shot. Please
>>>> discuss.
>>> 
>>> You are the one making proposal, you should come up with rationale. but ok
>> 
>> As I wrote, the rationale was discussed on this list between yesterday and
>> today. I’ll repeat it here. Now, you were the one saying there were
>> “problems”. I cannot guess the problems you have with my proposals if you
>> don’t discuss them.
>> 
>>> 
>>>> 
>>>>> 
>>> 
>>> - Use gitlab/github as primary, make freedesktop a mirror *?
>>> 
>>> What benefit does that bring?
>> 
>> It is to get these additional features, that AFAIK freedesktop lacks:
>> 
>> 1. Continuous integration
> 
> it can be done through mirrors (it is the case for the gitlab mirror)

Not for development branches. Today, it’s:

gitlab personal branch (some CI here)
a. send patch
b. someone else applies the patch and pushes to freedesktop (no CI here)
freedesktop replicated to gitlab after steps a and b have repeated a 
few times
CI applies to master on gitlab

So that means we run the CI tests only after multiple commits. I would like to 
migrate towards:

gitlab private branch (with CI)
merge request to gitlab/master (sends patch, etc)
merge to master (CI happens here too)

This ensures that CI tests run for every commit and before merge to master,
not once a day and after merge.

> 
>> 2. Merge requests or pull requests
>> 3. Being actually open (reported by Christophe Fergeau). For example, it took
>> me 6 months to get a working freedesktop account
> 
> Yeah, you have to ping someone to open the account

That would be OK if they were responsive. But multiple months vs. minutes for 
gitlab?

> 
>> 
>>> The canonical source is hosted on freedesktop for ages.
>> 
>> That does not need to change.
>> 
>>> The role of this is a stable & controlled git repo to pull/push code to.
>> 
>> Why do I get a sense that “controlled” is the keyword here? ;-)
>> 
>>> Moving it to a different location doesn't change that. Using github/gitlab
>>> as mirrors allows to have all the benefits of those hosting services.
>> 
>> To the best of my knowledge, that statement is incorrect
>> 
>> Specifically, we cannot enable merge requests on a mirror easily, because 
>> that
>> means if we accept the merge request on gitlab, then gitlab is ahead of
>> freedesktop, and when we push from freedesktop, that push is either rejected,
>> or if we use push -f, we lose the merge.
> 
> You never push to a mirror.

That’s exactly what I was saying ;-)

> 
>> 
>> Similarly, continuous integration on development branches,
> 
> Nothing block people from having ci/scripts to test their branches.

There is no incentive to do it either. Why replicate the effort?


> Nowadays people can fork our repos at gitlab and get a simple CI for free.
> We can give this advice in README.

That is a very good thing. Why did you share it? You should apply the same logic
that led you to sharing that work to the scripts/tests you talked about above.

> 
> Also a committer can push the patches to her/his gitlab fork to make sure
> everything is OK (before pushing to the main repo).
> 
>> i.e. before we actually merge them, is not possible with freedesktop, even
>> less so if your sense of “control” means you feel it’s OK to delete a review
>> branch I push there without asking me first. All that is a bit moot anyway,
>> because Google “freedesktop continuous integration” gives me nothing on the
>> first page. 
>> 
>>> So why?
>> 
>> Because I think that continuous integration and a list of pending merge
>> requests are more important than preserving the “we have been doing that for
>> ages” comfort zone.
>> 
>>> 
>>> - Rename spice as spice-server
>> 
>> - To unambiguously leave ‘spice’ as the name for a top-level repository.
>> - So that mail-processing script does not have to do extra ad-hockery to map

Re: [Spice-devel] [PATCH spice-gtk] Update submodules using the --merge option

[Christophe de Dinechin]

> On 28 Jul 2017, at 12:19, Marc-André Lureau <marcandre.lur...@redhat.com> 
> wrote:
> 
> Hi
> 
> - Original Message -----
>> From: Christophe de Dinechin <dinec...@redhat.com 
>> <mailto:dinec...@redhat.com>>
>> 
>> By default, subdmodules will be checked out in detached state.
>> This means that you may lose some work in progress.
> 
> Lose is a bit strong here.
> 
> If you have uncommitted changes, submodule update will fail.
> 
> If it's committed, it's in your reflog, and in which case you should have 
> created a branch for your work.

git submodule update often places submodules in detached head state,
even if you had created a branch beforehand.

> 
>> 
>> Using the --merge option will also ensure that if there
>> are conflicts between your current submodule and the
>> version referenced by the parent, you get an opportunity
>> to resolve the conflicts instead of having your changes
>> silently wiped out.
>> 
>> Signed-off-by: Christophe de Dinechin <dinec...@redhat.com>
>> ---
>> autogen.sh | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/autogen.sh b/autogen.sh
>> index cc7bda3..3fbd5b3 100755
>> --- a/autogen.sh
>> +++ b/autogen.sh
>> @@ -7,7 +7,7 @@ test -z "$srcdir" && srcdir=.
>> 
>> (
>> cd "$srcdir"
>> -git submodule update --init --recursive
>> +git submodule update --init --recursive --merge
> 
> I would rather use --rebase (to avoid accidental push of those update merges).

Why not. It will point out merge conflicts just the same.

> 
>> gtkdocize
>> autoreconf -v --force --install
>> )
>> --
>> 2.11.0 (Apple Git-81)
>> 
>> ___
>> Spice-devel mailing list
>> Spice-devel@lists.freedesktop.org <mailto:Spice-devel@lists.freedesktop.org>
>> https://lists.freedesktop.org/mailman/listinfo/spice-devel 
>> <https://lists.freedesktop.org/mailman/listinfo/spice-devel>
>> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org <mailto:Spice-devel@lists.freedesktop.org>
> https://lists.freedesktop.org/mailman/listinfo/spice-devel 
> <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] [PATCH spice-gtk] Update submodules using the --merge option

[Christophe de Dinechin]

> On 31 Jul 2017, at 10:58, Frediano Ziglio <fzig...@redhat.com> wrote:
> 
>> 
>> Hi
>> 
>> ----- Original Message -----
>>> From: Christophe de Dinechin <dinec...@redhat.com 
>>> <mailto:dinec...@redhat.com>>
>>> 
>>> By default, subdmodules will be checked out in detached state.
>>> This means that you may lose some work in progress.
>> 
>> Lose is a bit strong here.
>> 
>> If you have uncommitted changes, submodule update will fail.
>> 
> 
> This to me seems a good reason for a nack. The update will fail as
> a normal conflict without loosing any work.

Only if you have uncommitted changes. Otherwise, you end up
in detached head state. That’s OK if I run git submodule update
myself, I know what I’m doing. I’m more concerned about a builds script
doing that for me.

IOW, I don’t want to have some work in a submodule in branch “topic”,
and just because I ran autogen.sh, end up in detached head state with
a detached head that does not even contain my topic.

> 
>> If it's committed, it's in your reflog, and in which case you should have
>> created a branch for your work.
>> 
>>> 
>>> Using the --merge option will also ensure that if there
>>> are conflicts between your current submodule and the
>>> version referenced by the parent, you get an opportunity
>>> to resolve the conflicts instead of having your changes
>>> silently wiped out.
>>> 
>>> Signed-off-by: Christophe de Dinechin <dinec...@redhat.com>
>>> ---
>>> autogen.sh | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/autogen.sh b/autogen.sh
>>> index cc7bda3..3fbd5b3 100755
>>> --- a/autogen.sh
>>> +++ b/autogen.sh
>>> @@ -7,7 +7,7 @@ test -z "$srcdir" && srcdir=.
>>> 
>>> (
>>> cd "$srcdir"
>>> -git submodule update --init --recursive
>>> +git submodule update --init --recursive --merge
>> 
>> I would rather use --rebase (to avoid accidental push of those update
>> merges).
>> 
>>> gtkdocize
>>> autoreconf -v --force --install
>>> )
> 
> Frediano

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

[Spice-devel] Getting patchwork to acknowledge acks?

[Christophe de Dinechin]

During the discussion on PRs and stuff, several people pointed to patchwork.

Does anyone know why this tool does not acknowledge acks? For example 
https://patchwork.freedesktop.org/series/27298/ has a "Acked-by: Christophe de 
Dinechin <dinec...@redhat.com>” in the fifth comment, and has been merged as 
4cdd6e07d3f7ec07dccfa11c12099cb45ac60d3d. Yet it’s still marked as “New” by 
patchwork.

There are a few series marked as “Done”: 
https://patchwork.freedesktop.org/project/Spice/series/?ordering=-last_updated. 
For example, this one https://patchwork.freedesktop.org/series/25980/ was 
marked as “Done”. It’s recent (June 19). Christophe, did you explicitly mark it 
as “Done”, or is some fuzzy parser in patchwork smart enough to parse your 
"I've now pushed this upstream” comment?


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

Re: [Spice-devel] [PATCH spice-gtk v2] spice-gtk: Use time comparisons that still work after wraparound

[Christophe de Dinechin]

> On 18 Jul 2017, at 16:48, Christophe Fergeau <cferg...@redhat.com> wrote:
> 
> Hey,
> 
> On Tue, Jul 18, 2017 at 04:37:29PM +0200, Christophe de Dinechin wrote:
>> OK. Since you seem to feel more strongly about this than me, I changed it.
>> Pushed to freedesktop.org. Since this is the first time I push myself to 
>> this repo,
>> would you please be kind enough to check that what I pushed looks sane?
> 
> This looks all good, only minor comment I have is with the 'spice-gtk'
> prefix, you prepended it to the commit log, so it appears in git log, we
> usually use nothing, or a more specific prefix.
> The messages to the mailing list are prefixed with "spice-gtk", but
> through git send-email --subject-prefix spice-gtk.

Does that count as an “ack”? Or do you want me to resend the series with just 
the subject line change?

> 
> Christophe

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

Re: [Spice-devel] Getting patchwork to acknowledge acks?

[Christophe de Dinechin]

> On 4 Aug 2017, at 12:48, Victor Toso <victort...@redhat.com> wrote:
> 
> Hi,
> 
> On Fri, Aug 04, 2017 at 12:42:39PM +0200, Christophe de Dinechin wrote:
>> During the discussion on PRs and stuff, several people pointed to
>> patchwork.
>> 
>> Does anyone know why this tool does not acknowledge acks? For example
>> https://patchwork.freedesktop.org/series/27298/ has a "Acked-by:
>> Christophe de Dinechin <dinec...@redhat.com>” in the fifth comment,
>> and has been merged as 4cdd6e07d3f7ec07dccfa11c12099cb45ac60d3d. Yet
>> it’s still marked as “New” by patchwork.
> 
> It parses the acked-by and does +1 per-patch
> https://patchwork.freedesktop.org/project/Spice/patches/

It does not seem too smart about it though. I wrote “can’t ack right now”, and 
it apparently counted that as a second “ack” :-D

> 
> That`s the only automated feature that it does, afaik.
> 
>> There are a few series marked as “Done”:
>> https://patchwork.freedesktop.org/project/Spice/series/?ordering=-last_updated.
>> For example, this one https://patchwork.freedesktop.org/series/25980/
>> was marked as “Done”. It’s recent (June 19). Christophe, did you
>> explicitly mark it as “Done”, or is some fuzzy parser in patchwork
>> smart enough to parse your "I've now pushed this upstream” comment?
>> 
>> Christophe
> 
> It does not check if given patch was pushed, no. :(

If so, that’s a lot less useful than PRs.


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

[Spice-devel] [PATCH spice-gtk] Fix occasional black screen at startup

[Christophe de Dinechin]

From: Christophe de Dinechin <dinec...@redhat.com>

The problem occurs when we call spice_playback_channel_set_delay before
the channel had received any data setting c->last_time, but after
session initialization had set mm_time in the session. The result was
that the (good) value in session->mm_time would be overwritten with 0.

Signed-off-by: Christophe de Dinechin <dinec...@redhat.com>
---
 src/channel-playback.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/channel-playback.c b/src/channel-playback.c
index ca14b96..f5acf23 100644
--- a/src/channel-playback.c
+++ b/src/channel-playback.c
@@ -471,7 +471,8 @@ void spice_playback_channel_set_delay(SpicePlaybackChannel 
*channel, guint32 del
 
 session = spice_channel_get_session(SPICE_CHANNEL(channel));
 if (session) {
-spice_session_set_mm_time(session, c->last_time - delay_ms);
+if (c->last_time != 0)
+spice_session_set_mm_time(session, c->last_time - delay_ms);
 } else {
 CHANNEL_DEBUG(channel, "channel detached from session, mm time 
skipped");
 }
-- 
2.11.0 (Apple Git-81)

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

[Spice-devel] [PATCH spice-gtk] spice-gtk: Use time comparisons that still work after wraparound

[Christophe de Dinechin]

From: Christophe de Dinechin <dinec...@redhat.com>

The mm timer is a millisecond timer that wraps around after ~49 days.
All comparisons that look like a
---
 src/channel-display-gst.c   | 4 ++--
 src/channel-display-mjpeg.c | 4 ++--
 src/channel-display.c   | 2 +-
 src/channel-playback.c  | 2 +-
 src/spice-channel-priv.h| 5 +
 src/spice-session.c | 4 ++--
 6 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 3cf451b..495036f 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@ -166,7 +166,7 @@ static void schedule_frame(SpiceGstDecoder *decoder)
 break;
 }
 
-if (now < gstframe->frame->mm_time) {
+if (spice_mm_strictly_before(now, gstframe->frame->mm_time)) {
 decoder->timer_id = g_timeout_add(gstframe->frame->mm_time - now,
   display_frame, decoder);
 } else if (g_queue_get_length(decoder->display_queue) == 1) {
@@ -509,7 +509,7 @@ static gboolean spice_gst_decoder_queue_frame(VideoDecoder 
*video_decoder,
 return TRUE;
 }
 
-if (frame->mm_time < decoder->last_mm_time) {
+if (spice_mm_strictly_before(frame->mm_time, decoder->last_mm_time)) {
 SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
 " resetting stream",
 frame->mm_time, decoder->last_mm_time);
diff --git a/src/channel-display-mjpeg.c b/src/channel-display-mjpeg.c
index ee33b01..c91fa53 100644
--- a/src/channel-display-mjpeg.c
+++ b/src/channel-display-mjpeg.c
@@ -201,7 +201,7 @@ static void mjpeg_decoder_schedule(MJpegDecoder *decoder)
 decoder->cur_frame = NULL;
 do {
 if (frame) {
-if (time <= frame->mm_time) {
+if (spice_mm_before(time, frame->mm_time)) {
 guint32 d = frame->mm_time - time;
 decoder->cur_frame = frame;
 decoder->timer_id = g_timeout_add(d, 
mjpeg_decoder_decode_frame, decoder);
@@ -251,7 +251,7 @@ static gboolean mjpeg_decoder_queue_frame(VideoDecoder 
*video_decoder,
 
 last_frame = g_queue_peek_tail(decoder->msgq);
 if (last_frame) {
-if (frame->mm_time < last_frame->mm_time) {
+if (spice_mm_strictly_before(frame->mm_time, last_frame->mm_time)) {
 /* This should really not happen */
 SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
 " resetting stream",
diff --git a/src/channel-display.c b/src/channel-display.c
index 3c98d79..fe7506e 100644
--- a/src/channel-display.c
+++ b/src/channel-display.c
@@ -1366,7 +1366,7 @@ static void 
display_update_stream_report(SpiceDisplayChannel *channel, uint32_t
 }
 
 if (st->report_num_frames >= st->report_max_window ||
-now - st->report_start_time >= st->report_timeout ||
+spice_mm_after(now - st->report_start_time, st->report_timeout) ||
 st->report_drops_seq_len >= STREAM_REPORT_DROP_SEQ_LEN_LIMIT) {
 SpiceMsgcDisplayStreamReport report;
 SpiceSession *session = 
spice_channel_get_session(SPICE_CHANNEL(channel));
diff --git a/src/channel-playback.c b/src/channel-playback.c
index ca14b96..451dfaf 100644
--- a/src/channel-playback.c
+++ b/src/channel-playback.c
@@ -313,7 +313,7 @@ static void playback_handle_data(SpiceChannel *channel, 
SpiceMsgIn *in)
   packet->time, packet->data, packet->data_size);
 #endif
 
-if (c->last_time > packet->time)
+if (spice_mm_strictly_after(c->last_time, packet->time))
 g_warn_if_reached();
 
 c->last_time = packet->time;
diff --git a/src/spice-channel-priv.h b/src/spice-channel-priv.h
index 7288920..b896aaa 100644
--- a/src/spice-channel-priv.h
+++ b/src/spice-channel-priv.h
@@ -43,6 +43,11 @@ G_BEGIN_DECLS
 #define CHANNEL_DEBUG(channel, fmt, ...) \
 SPICE_DEBUG("%s: " fmt, SPICE_CHANNEL(channel)->priv->name, ## __VA_ARGS__)
 
+#define spice_mm_after(now, time)   ((int32_t) ((now)-(time)) >= 0)
+#define spice_mm_before(now, time)  ((int32_t) ((now)-(time)) <= 0)
+#define spice_mm_strictly_after(now, time)  ((int32_t) ((now)-(time)) > 0)
+#define spice_mm_strictly_before(now, time) ((int32_t) ((now)-(time)) < 0)
+
 struct _SpiceMsgOut {
 int   refcount;
 SpiceChannel  *channel;
diff --git a/src/spice-session.c b/src/spice-session.c
index 6f8cf5e..62b041e 100644
--- a/src/spice-session.c
+++ b/src/spice-session.c
@@ -2336,8 +2336,8 @@ void spice_session_set_mm_time(SpiceSession *session, 
guint32 time)
 s->mm_time = time;
 s->mm_time_at_clock = g_get_monotonic_time();
 SPICE_DEBUG("set mm time: 

[Spice-devel] [PATCH spice-gtk 1/3] Add SPICE_TWEAK_DEFINE and SPICE_TWEAK macros

[Christophe de Dinechin]

From: Christophe de Dinechin <dinec...@redhat.com>

These two macros are intended to identify places in the code where there
are ad-hoc values that can be tweaked to optimize behavior. They may be
connected later to a mechanism that allows such "tweaks" to be made
without recompiling, e.g. by passing environment variables.

Signed-off-by: Christophe de Dinechin <dinec...@redhat.com>
---
 src/spice-util.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/spice-util.h b/src/spice-util.h
index 1d80f1c..9aa346b 100644
--- a/src/spice-util.h
+++ b/src/spice-util.h
@@ -38,6 +38,9 @@ gchar* spice_uuid_to_string(const guint8 uuid[16]);
 g_debug(G_STRLOC " " fmt, ## __VA_ARGS__);  \
 } while (0)
 
+#define SPICE_TWEAK_DEFINE(Name, Value, Description)gint64 Name = Value
+#define SPICE_TWEAK(Name)   (Name)
+
 #define SPICE_RESERVED_PADDING (10 * sizeof(void*))
 
 G_END_DECLS
-- 
2.11.0 (Apple Git-81)

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

[Spice-devel] [PATCH spice-gtk 2/3] Drop frames if the backlog is above some limit

[Christophe de Dinechin]

From: Christophe de Dinechin <dinec...@redhat.com>

Experience has shown that if the machine running the guest is overloaded,
it may pile up a lot of backlog in the frames queue. This patch clears
the queue if it exceeds 100 entries. This value is arbitrary. It
corresponds to a few seconds on a highly overloaded machine.

Signed-off-by: Christophe de Dinechin <dinec...@redhat.com>
---
 src/channel-display-gst.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 3cf451b..17c2847 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@ -498,6 +498,9 @@ static void spice_gst_decoder_destroy(VideoDecoder 
*video_decoder)
  * 9) display_frame() then frees the SpiceGstFrame, which frees the SpiceFrame
  *and decompressed frame with it.
  */
+
+SPICE_TWEAK_DEFINE(gst_queue_max_length, 100, "Max length of GStreamer queue");
+
 static gboolean spice_gst_decoder_queue_frame(VideoDecoder *video_decoder,
   SpiceFrame *frame, int latency)
 {
@@ -541,6 +544,16 @@ static gboolean spice_gst_decoder_queue_frame(VideoDecoder 
*video_decoder,
 }
 #endif
 
+if (SPICE_TWEAK(gst_queue_max_length) &&
+decoder->decoding_queue->length > SPICE_TWEAK(gst_queue_max_length)) {
+   SpiceGstFrame *gstframe;
+   g_mutex_lock(>queues_mutex);
+while ((gstframe = g_queue_pop_head(decoder->decoding_queue)))
+free_gst_frame(gstframe);
+g_mutex_unlock(>queues_mutex);
+return TRUE;
+}
+
 /* ref() the frame data for the buffer */
 frame->ref_data(frame->data_opaque);
 GstBuffer *buffer = 
gst_buffer_new_wrapped_full(GST_MEMORY_FLAG_PHYSICALLY_CONTIGUOUS,
-- 
2.11.0 (Apple Git-81)

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

[Spice-devel] [PATCH spice-gtk 0/3] spice-gtk: Drop frames if they pile up because client is overloaded

[Christophe de Dinechin]

From: Christophe de Dinechin <dinec...@redhat.com>

This patch series is a crude attempt at getting rid of the frames backlog
when the spice client is overloaded. Another parameter I have been
playing wiht is the max-bytes parameter in the GStreamer
pipeline, which is currently set to 0 (unlimited), which is probably
a lot more than necessary.

I am still experimenting to figure out the correct values, and I am
considering less agressive heuristics than dropping *all* the
frames. I am also not entirely convinced that returning TRUE when we
clear the frames is the right thing to do. It looks like falling
through is another valid option. This is particularly true if the
frame is an I-frame.

I share this patch as is as an illustration of a scenario
where it is nice to be able to tweak parameters dynamically for
experimentation purpose. In my 'recorder' branch, the tweaks are
dynamic and defined using an environment variable.

Christophe de Dinechin (3):
  Add SPICE_TWEAK_DEFINE and SPICE_TWEAK macros
  Drop frames if the backlog is above some limit
  Add configurable value for gst_max_bytes

 src/channel-display-gst.c | 18 +-
 src/spice-util.h  |  3 +++
 2 files changed, 20 insertions(+), 1 deletion(-)

-- 
2.11.0 (Apple Git-81)

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

[Spice-devel] [PATCH spice-gtk 3/3] Add configurable value for gst_max_bytes

[Christophe de Dinechin]

From: Christophe de Dinechin <dinec...@redhat.com>

The GStreamer configuration currently sets max-bytes=0 in the pipeline.
The rationale is that we need to be able to keep frames in case later frames
require them for decoding. However, having experienced scenarios where
spice would accumulate gigabytes of late frames. So it would be useful
to be able to configure that value at runtime.

Signed-off-by: Christophe de Dinechin <dinec...@redhat.com>
---
 src/channel-display-gst.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index 17c2847..b60c7df 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@ -332,6 +332,8 @@ static void app_source_setup(GstElement *pipeline 
G_GNUC_UNUSED,
 }
 #endif
 
+SPICE_TWEAK_DEFINE(gst_max_bytes, 0, "Max number of bytes queued, 
0=unlimited");
+
 static gboolean create_pipeline(SpiceGstDecoder *decoder)
 {
 GstAppSinkCallbacks appsink_cbs = { NULL };
@@ -388,9 +390,10 @@ static gboolean create_pipeline(SpiceGstDecoder *decoder)
  * - Set max-bytes=0 on appsrc so it does not drop frames that may be
  *   needed by those that follow.
  */
-desc = g_strdup_printf("appsrc name=src is-live=true format=time 
max-bytes=0 block=true "
+desc = g_strdup_printf("appsrc name=src is-live=true format=time 
max-bytes=%lu block=true "
"caps=%s ! %s ! videoconvert ! appsink name=sink "
"caps=video/x-raw,format=BGRx sync=false 
drop=false",
+   SPICE_TWEAK(gst_max_bytes),
gst_opts[decoder->base.codec_type].dec_caps,
gst_opts[decoder->base.codec_type].dec_name);
 SPICE_DEBUG("GStreamer pipeline: %s", desc);
-- 
2.11.0 (Apple Git-81)

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

Re: [Spice-devel] [PATCH spice-gtk v2] spice-gtk: Use time comparisons that still work after wraparound

[Christophe de Dinechin]

> On 17 Jul 2017, at 13:49, Christophe Fergeau <cferg...@redhat.com 
> <mailto:cferg...@redhat.com>> wrote:
> 
> On Mon, Jul 17, 2017 at 11:44:04AM +0200, Christophe de Dinechin wrote:
>> From: Christophe de Dinechin <dinec...@redhat.com 
>> <mailto:dinec...@redhat.com>>
>> 
>> The mm timer is a millisecond timer that wraps around after ~49 days.
>> All comparisons that look like a> Instead, use signed ((int)(a-b)<0), which may fail if there is more than
>> 25 days between a and b (should not be happening under normal conditions),
>> but is robust to the timer wrapping around.
>> 
>> Signed-off-by: Christophe de Dinechin <dinec...@redhat.com 
>> <mailto:dinec...@redhat.com>>
>> ---
>> src/channel-display-gst.c   | 4 ++--
>> src/channel-display-mjpeg.c | 4 ++--
>> src/channel-display.c   | 2 +-
>> src/channel-playback.c  | 2 +-
>> src/spice-channel-priv.h| 2 ++
>> src/spice-session.c | 4 ++--
>> 6 files changed, 10 insertions(+), 8 deletions(-)
>> 
>> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
>> index adcd6ef..3f51361 100644
>> --- a/src/channel-display-gst.c
>> +++ b/src/channel-display-gst.c
>> @@ -166,7 +166,7 @@ static void schedule_frame(SpiceGstDecoder *decoder)
>> break;
>> }
>> 
>> -if (now < gstframe->frame->mm_time) {
>> +if (spice_mmtime_diff(now, gstframe->frame->mm_time) < 0) {
>> decoder->timer_id = g_timeout_add(gstframe->frame->mm_time - now,
>>   display_frame, decoder);
>> } else if (g_queue_get_length(decoder->display_queue) == 1) {
>> @@ -511,7 +511,7 @@ static gboolean 
>> spice_gst_decoder_queue_frame(VideoDecoder *video_decoder,
>> return TRUE;
>> }
>> 
>> -if (frame->mm_time < decoder->last_mm_time) {
>> +if (spice_mmtime_diff(frame->mm_time, decoder->last_mm_time) < 0) {
>> SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
>> " resetting stream",
>> frame->mm_time, decoder->last_mm_time);
>> diff --git a/src/channel-display-mjpeg.c b/src/channel-display-mjpeg.c
>> index ee33b01..3ba098c 100644
>> --- a/src/channel-display-mjpeg.c
>> +++ b/src/channel-display-mjpeg.c
>> @@ -201,7 +201,7 @@ static void mjpeg_decoder_schedule(MJpegDecoder *decoder)
>> decoder->cur_frame = NULL;
>> do {
>> if (frame) {
>> -if (time <= frame->mm_time) {
>> +if (spice_mmtime_diff(time, frame->mm_time) <= 0) {
>> guint32 d = frame->mm_time - time;
>> decoder->cur_frame = frame;
>> decoder->timer_id = g_timeout_add(d, 
>> mjpeg_decoder_decode_frame, decoder);
>> @@ -251,7 +251,7 @@ static gboolean mjpeg_decoder_queue_frame(VideoDecoder 
>> *video_decoder,
>> 
>> last_frame = g_queue_peek_tail(decoder->msgq);
>> if (last_frame) {
>> -if (frame->mm_time < last_frame->mm_time) {
>> +if (spice_mmtime_diff(frame->mm_time, last_frame->mm_time) < 0) {
>> /* This should really not happen */
>> SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
>> " resetting stream",
>> diff --git a/src/channel-display.c b/src/channel-display.c
>> index 3c98d79..06ed18a 100644
>> --- a/src/channel-display.c
>> +++ b/src/channel-display.c
>> @@ -1366,7 +1366,7 @@ static void 
>> display_update_stream_report(SpiceDisplayChannel *channel, uint32_t
>> }
>> 
>> if (st->report_num_frames >= st->report_max_window ||
>> -now - st->report_start_time >= st->report_timeout ||
>> +spice_mmtime_diff(now - st->report_start_time, st->report_timeout) 
>> >= 0 ||
>> st->report_drops_seq_len >= STREAM_REPORT_DROP_SEQ_LEN_LIMIT) {
>> SpiceMsgcDisplayStreamReport report;
>> SpiceSession *session = 
>> spice_channel_get_session(SPICE_CHANNEL(channel));
>> diff --git a/src/channel-playback.c b/src/channel-playback.c
>> index ca14b96..afc9059 100644
>> --- a/src/channel-playback.c
>> +++ b/src/channel-playback.c
>> @@ -313,7 +313,7 @@ static void playback_handle_data(SpiceChannel *channel, 
>> SpiceMsgIn *in)
>>   packet->time, packet->data, pac

Re: [Spice-devel] [PATCH spice-gtk] spice-gtk: Use time comparisons that still work after wraparound

[Christophe de Dinechin]

> On 17 Jul 2017, at 10:33, Christophe Fergeau <cferg...@redhat.com> wrote:
> 
> On Thu, Jul 13, 2017 at 04:21:36PM +0200, Christophe de Dinechin wrote:
>> From: Christophe de Dinechin <dinec...@redhat.com>
>> 
>> The mm timer is a millisecond timer that wraps around after ~49 days.
>> All comparisons that look like a> Instead, use signed ((int)(a-b)<0), which may fail if there is more than
>> 25 days between a and b (should not be happening under normal conditions),
>> but is robust to the timer wrapping around.
> 
> Have you considered having a spice_mm_difftime() helper rather than
> introducing 4 different ones? (less than, strictly less than, more than,
> strictly more than)

Well, you are right, spice_mm_difftime(now, then) < 0 may be easier to read… It 
also opens options with things like spice_mm_difftime(now, then) < threshold. 
Will do that.

Christophe

> 
> Christophe
> 
>> 
>> Signed-off-by: Christophe de Dinechin <dinec...@redhat.com>
>> ---
>> src/channel-display-gst.c   | 4 ++--
>> src/channel-display-mjpeg.c | 4 ++--
>> src/channel-display.c   | 2 +-
>> src/channel-playback.c  | 2 +-
>> src/spice-channel-priv.h| 5 +
>> src/spice-session.c | 4 ++--
>> 6 files changed, 13 insertions(+), 8 deletions(-)
>> 
>> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
>> index 3cf451b..495036f 100644
>> --- a/src/channel-display-gst.c
>> +++ b/src/channel-display-gst.c
>> @@ -166,7 +166,7 @@ static void schedule_frame(SpiceGstDecoder *decoder)
>>   break;
>>   }
>> 
>> -if (now < gstframe->frame->mm_time) {
>> +if (spice_mm_strictly_before(now, gstframe->frame->mm_time)) {
>>   decoder->timer_id = g_timeout_add(gstframe->frame->mm_time - now,
>> display_frame, decoder);
>>   } else if (g_queue_get_length(decoder->display_queue) == 1) {
>> @@ -509,7 +509,7 @@ static gboolean 
>> spice_gst_decoder_queue_frame(VideoDecoder *video_decoder,
>>   return TRUE;
>>   }
>> 
>> -if (frame->mm_time < decoder->last_mm_time) {
>> +if (spice_mm_strictly_before(frame->mm_time, decoder->last_mm_time)) {
>>   SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
>>   " resetting stream",
>>   frame->mm_time, decoder->last_mm_time);
>> diff --git a/src/channel-display-mjpeg.c b/src/channel-display-mjpeg.c
>> index ee33b01..c91fa53 100644
>> --- a/src/channel-display-mjpeg.c
>> +++ b/src/channel-display-mjpeg.c
>> @@ -201,7 +201,7 @@ static void mjpeg_decoder_schedule(MJpegDecoder *decoder)
>>   decoder->cur_frame = NULL;
>>   do {
>>   if (frame) {
>> -if (time <= frame->mm_time) {
>> +if (spice_mm_before(time, frame->mm_time)) {
>>   guint32 d = frame->mm_time - time;
>>   decoder->cur_frame = frame;
>>   decoder->timer_id = g_timeout_add(d, 
>> mjpeg_decoder_decode_frame, decoder);
>> @@ -251,7 +251,7 @@ static gboolean mjpeg_decoder_queue_frame(VideoDecoder 
>> *video_decoder,
>> 
>>   last_frame = g_queue_peek_tail(decoder->msgq);
>>   if (last_frame) {
>> -if (frame->mm_time < last_frame->mm_time) {
>> +if (spice_mm_strictly_before(frame->mm_time, last_frame->mm_time)) {
>>   /* This should really not happen */
>>   SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
>>   " resetting stream",
>> diff --git a/src/channel-display.c b/src/channel-display.c
>> index 3c98d79..fe7506e 100644
>> --- a/src/channel-display.c
>> +++ b/src/channel-display.c
>> @@ -1366,7 +1366,7 @@ static void 
>> display_update_stream_report(SpiceDisplayChannel *channel, uint32_t
>>   }
>> 
>>   if (st->report_num_frames >= st->report_max_window ||
>> -now - st->report_start_time >= st->report_timeout ||
>> +spice_mm_after(now - st->report_start_time, st->report_timeout) ||
>>   st->report_drops_seq_len >= STREAM_REPORT_DROP_SEQ_LEN_LIMIT) {
>>   SpiceMsgcDisplayStreamReport report;
>>   SpiceSession *session = 
>> spice_channel_get_session(SPICE_CHANNEL(channel));
>> diff --git a/src/channel-playback.c b/src/channel-playback.c
>> index ca14b96..451dfaf 100644
>> --- a/src/channel-playback.c
>> +++

[Spice-devel] [PATCH spice-gtk v2] spice-gtk: Use time comparisons that still work after wraparound

[Christophe de Dinechin]

From: Christophe de Dinechin <dinec...@redhat.com>

The mm timer is a millisecond timer that wraps around after ~49 days.
All comparisons that look like a
---
 src/channel-display-gst.c   | 4 ++--
 src/channel-display-mjpeg.c | 4 ++--
 src/channel-display.c   | 2 +-
 src/channel-playback.c  | 2 +-
 src/spice-channel-priv.h| 2 ++
 src/spice-session.c | 4 ++--
 6 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
index adcd6ef..3f51361 100644
--- a/src/channel-display-gst.c
+++ b/src/channel-display-gst.c
@@ -166,7 +166,7 @@ static void schedule_frame(SpiceGstDecoder *decoder)
 break;
 }
 
-if (now < gstframe->frame->mm_time) {
+if (spice_mmtime_diff(now, gstframe->frame->mm_time) < 0) {
 decoder->timer_id = g_timeout_add(gstframe->frame->mm_time - now,
   display_frame, decoder);
 } else if (g_queue_get_length(decoder->display_queue) == 1) {
@@ -511,7 +511,7 @@ static gboolean spice_gst_decoder_queue_frame(VideoDecoder 
*video_decoder,
 return TRUE;
 }
 
-if (frame->mm_time < decoder->last_mm_time) {
+if (spice_mmtime_diff(frame->mm_time, decoder->last_mm_time) < 0) {
 SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
 " resetting stream",
 frame->mm_time, decoder->last_mm_time);
diff --git a/src/channel-display-mjpeg.c b/src/channel-display-mjpeg.c
index ee33b01..3ba098c 100644
--- a/src/channel-display-mjpeg.c
+++ b/src/channel-display-mjpeg.c
@@ -201,7 +201,7 @@ static void mjpeg_decoder_schedule(MJpegDecoder *decoder)
 decoder->cur_frame = NULL;
 do {
 if (frame) {
-if (time <= frame->mm_time) {
+if (spice_mmtime_diff(time, frame->mm_time) <= 0) {
 guint32 d = frame->mm_time - time;
 decoder->cur_frame = frame;
 decoder->timer_id = g_timeout_add(d, 
mjpeg_decoder_decode_frame, decoder);
@@ -251,7 +251,7 @@ static gboolean mjpeg_decoder_queue_frame(VideoDecoder 
*video_decoder,
 
 last_frame = g_queue_peek_tail(decoder->msgq);
 if (last_frame) {
-if (frame->mm_time < last_frame->mm_time) {
+if (spice_mmtime_diff(frame->mm_time, last_frame->mm_time) < 0) {
 /* This should really not happen */
 SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
 " resetting stream",
diff --git a/src/channel-display.c b/src/channel-display.c
index 3c98d79..06ed18a 100644
--- a/src/channel-display.c
+++ b/src/channel-display.c
@@ -1366,7 +1366,7 @@ static void 
display_update_stream_report(SpiceDisplayChannel *channel, uint32_t
 }
 
 if (st->report_num_frames >= st->report_max_window ||
-now - st->report_start_time >= st->report_timeout ||
+spice_mmtime_diff(now - st->report_start_time, st->report_timeout) >= 
0 ||
 st->report_drops_seq_len >= STREAM_REPORT_DROP_SEQ_LEN_LIMIT) {
 SpiceMsgcDisplayStreamReport report;
 SpiceSession *session = 
spice_channel_get_session(SPICE_CHANNEL(channel));
diff --git a/src/channel-playback.c b/src/channel-playback.c
index ca14b96..afc9059 100644
--- a/src/channel-playback.c
+++ b/src/channel-playback.c
@@ -313,7 +313,7 @@ static void playback_handle_data(SpiceChannel *channel, 
SpiceMsgIn *in)
   packet->time, packet->data, packet->data_size);
 #endif
 
-if (c->last_time > packet->time)
+if (spice_mmtime_diff(c->last_time, packet->time) > 0)
 g_warn_if_reached();
 
 c->last_time = packet->time;
diff --git a/src/spice-channel-priv.h b/src/spice-channel-priv.h
index 7288920..20d3495 100644
--- a/src/spice-channel-priv.h
+++ b/src/spice-channel-priv.h
@@ -43,6 +43,8 @@ G_BEGIN_DECLS
 #define CHANNEL_DEBUG(channel, fmt, ...) \
 SPICE_DEBUG("%s: " fmt, SPICE_CHANNEL(channel)->priv->name, ## __VA_ARGS__)
 
+#define spice_mmtime_diff(now, time)((int32_t) ((now)-(time)))
+
 struct _SpiceMsgOut {
 int   refcount;
 SpiceChannel  *channel;
diff --git a/src/spice-session.c b/src/spice-session.c
index 6f8cf5e..a729cc3 100644
--- a/src/spice-session.c
+++ b/src/spice-session.c
@@ -2336,8 +2336,8 @@ void spice_session_set_mm_time(SpiceSession *session, 
guint32 time)
 s->mm_time = time;
 s->mm_time_at_clock = g_get_monotonic_time();
 SPICE_DEBUG("set mm time: %u", spice_session_get_mm_time(session));
-if (time > old_time + MM_TIME_DIFF_RESET_THRESH ||
-time < old_time) {
+if (spice_mmtime_diff(time, old_time + MM_TIME_DIFF_RESET_THRESH) > 0 |

Re: [Spice-devel] [PATCH spice-gtk v2] spice-gtk: Use time comparisons that still work after wraparound

[Christophe de Dinechin]

> On 18 Jul 2017, at 16:48, Christophe Fergeau <cferg...@redhat.com> wrote:
> 
> Hey,
> 
> On Tue, Jul 18, 2017 at 04:37:29PM +0200, Christophe de Dinechin wrote:
>> OK. Since you seem to feel more strongly about this than me, I changed it.
>> Pushed to freedesktop.org. Since this is the first time I push myself to 
>> this repo,
>> would you please be kind enough to check that what I pushed looks sane?
> 
> This looks all good, only minor comment I have is with the 'spice-gtk'
> prefix, you prepended it to the commit log, so it appears in git log, we
> usually use nothing, or a more specific prefix.

OK. For my education, what would you suggest as being an acceptable
more specific prefix be in that case, if any?

> The messages to the mailing list are prefixed with "spice-gtk", but
> through git send-email --subject-prefix spice-gtk.

OK. Deal.

Christophe
> 
> Christophe

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

Re: [Spice-devel] [PATCH spice-gtk] gst-audio: Do not update mmtime without real audio channel

[Christophe de Dinechin]

On 14 Jul 2017, at 14:27, Christophe de Dinechin <dinec...@redhat.com> wrote:
> 
> This looks better than my fix. Can’t ack right now (I did not build and test 
> it yet), but that looks like a reasonable approach
> 
>> On 14 Jul 2017, at 14:24, Pavel Grunt <pgr...@redhat.com> wrote:
>> 
>> This also fixes the huge memore leak reported by Christophe.
>> Steps to reproduce:
>> 1. ./configure --disable-pulse --enable-gstaudio
>> 2. connect to a vm streaming video with no audio playing
>> 3. see the memory grow really fast
>> 
>> It seems to be due to the fact that the "fake audio" channel updates the 
>> mmtime
>> in a way that schedules the frames to the future ((unsigned) 0 - delay) and 
>> then
>> gstreamer starts to queue the frames (they should be played later)
>> 
>> Pavel
>> 
>> On Fri, 2017-07-14 at 13:19 +0200, Pavel Grunt wrote:
>>> The fake channel has been introduced to get the audio volume by starting
>>> the gstreamer's audio pipeline and querring its volume info (see commit
>>> aa8d044417bbf60685f59163b874ecb4f157c3c9).
>>> 
>>> Hovewer starting the pipeline updates the mmtime as a side effect. This
>>> may cause a (big) delay in displaying a video stream.
>>> 
>>> Because the fake channel is only needed to get the volume info, make
>>> sure to not update the mm-time with it.
>>> 
>>> Reported-by: Christophe de Dinechin <dinec...@redhat.com>
>>> ---
>>> src/spice-gstaudio.c | 11 +++
>>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/src/spice-gstaudio.c b/src/spice-gstaudio.c
>>> index 014c3a5..715f824 100644
>>> --- a/src/spice-gstaudio.c
>>> +++ b/src/spice-gstaudio.c
>>> @@ -38,6 +38,7 @@ struct stream {
>>>GstElement  *sink;
>>>guint   rate;
>>>guint   channels;
>>> +gbooleanfake; /* fake channel just for getting info 
>>> about
>>> audio (volume) */
>>> };
>>> 
>>> struct _SpiceGstaudioPrivate {
>>> @@ -264,6 +265,8 @@ static gboolean update_mmtime_timeout_cb(gpointer data)
>>>SpiceGstaudioPrivate *p = gstaudio->priv;
>>>GstQuery *q;
>>> 
>>> +g_return_val_if_fail(!p->playback.fake, TRUE);
>>> +
>>>q = gst_query_new_latency();
>>>if (gst_element_query(p->playback.pipe, q)) {
>>>gboolean live;
>>> @@ -326,7 +329,7 @@ cleanup:
>>>if (p->playback.pipe)
>>>gst_element_set_state(p->playback.pipe, GST_STATE_PLAYING);
>>> 
>>> -if (p->mmtime_id == 0) {
>>> +if (!p->playback.fake && p->mmtime_id == 0) {
>>>update_mmtime_timeout_cb(gstaudio);
>>>p->mmtime_id = g_timeout_add_seconds(1, update_mmtime_timeout_cb,
>>> gstaudio);
>>>}
>>> @@ -569,7 +572,6 @@ static gboolean
>>> spice_gstaudio_get_playback_volume_info_finish(SpiceAudio *audio
>>>GstElement *e;
>>>gboolean lmute;
>>>gdouble vol;
>>> -gboolean fake_channel = FALSE;
>>>GTask *task = G_TASK(res);
>>> 
>>>g_return_val_if_fail(g_task_is_valid(task, audio), FALSE);
>>> @@ -584,9 +586,9 @@ static gboolean
>>> spice_gstaudio_get_playback_volume_info_finish(SpiceAudio *audio
>>> 
>>>if (p->playback.sink == NULL || p->playback.channels == 0) {
>>>SPICE_DEBUG("PlaybackChannel not created yet, force start");
>>> +p->playback.fake = TRUE;
>>>/* In order to get system volume, we start the pipeline */
>>>playback_start(NULL, SPICE_AUDIO_FMT_S16, 2, 48000, audio);
>>> -fake_channel = TRUE;
>>>}
>>> 
>>>if (GST_IS_BIN(p->playback.sink))
>>> @@ -604,9 +606,10 @@ static gboolean
>>> spice_gstaudio_get_playback_volume_info_finish(SpiceAudio *audio
>>>}
>>>g_object_unref(e);
>>> 
>>> -if (fake_channel) {
>>> +if (p->playback.fake) {
>>>SPICE_DEBUG("Stop faked PlaybackChannel");
>>>playback_stop(SPICE_GSTAUDIO(audio));
>>> +p->playback.fake = FALSE;
>>>}
>>> 
>>>if (mute != NULL) {

This fixes the issue I was seeing with a black screen.

Acked-by: Christophe de Dinechin <dinec...@redhat.com>

> 
> ___
> 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] [PATCH spice-gtk] gst-audio: Do not update mmtime without real audio channel

[Christophe de Dinechin]

> On 18 Jul 2017, at 17:12, Uri Lublin <u...@redhat.com> wrote:
> 
> Hi Pavel,
> 
> Some typos below.
> 
> On 07/14/2017 02:19 PM, Pavel Grunt wrote:
>> The fake channel has been introduced to get the audio volume by starting
>> the gstreamer's audio pipeline and querring its volume info (see commit
> 
> querring -> querying
> 
>> aa8d044417bbf60685f59163b874ecb4f157c3c9).
>> Hovewer starting the pipeline updates the mmtime as a side effect. This
> 
> Hovewer -> However

Ach, shoot, I just pushed it seconds ago…

> 
> Uri.
> 
>> may cause a (big) delay in displaying a video stream.
>> Because the fake channel is only needed to get the volume info, make
>> sure to not update the mm-time with it.
>> Reported-by: Christophe de Dinechin <dinec...@redhat.com>
> ___
> 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] [PATCH spice-gtk v2] spice-gtk: Use time comparisons that still work after wraparound

[Christophe de Dinechin]

> 
> On 17 Jul 2017, at 14:20, Christophe Fergeau <cferg...@redhat.com> wrote:
> 
> On Mon, Jul 17, 2017 at 02:00:01PM +0200, Christophe de Dinechin wrote:
>> 
>>> On 17 Jul 2017, at 13:49, Christophe Fergeau <cferg...@redhat.com 
>>> <mailto:cferg...@redhat.com>> wrote:
>>> 
>>> On Mon, Jul 17, 2017 at 11:44:04AM +0200, Christophe de Dinechin wrote:
>>>> From: Christophe de Dinechin <dinec...@redhat.com 
>>>> <mailto:dinec...@redhat.com>>
>>>> 
>>>> The mm timer is a millisecond timer that wraps around after ~49 days.
>>>> All comparisons that look like a>>> Instead, use signed ((int)(a-b)<0), which may fail if there is more than
>>>> 25 days between a and b (should not be happening under normal conditions),
>>>> but is robust to the timer wrapping around.
>>>> 
>>>> Signed-off-by: Christophe de Dinechin <dinec...@redhat.com 
>>>> <mailto:dinec...@redhat.com>>
>>>> ---
>>>> src/channel-display-gst.c   | 4 ++--
>>>> src/channel-display-mjpeg.c | 4 ++--
>>>> src/channel-display.c   | 2 +-
>>>> src/channel-playback.c  | 2 +-
>>>> src/spice-channel-priv.h| 2 ++
>>>> src/spice-session.c | 4 ++--
>>>> 6 files changed, 10 insertions(+), 8 deletions(-)
>>>> 
>>>> diff --git a/src/channel-display-gst.c b/src/channel-display-gst.c
>>>> index adcd6ef..3f51361 100644
>>>> --- a/src/channel-display-gst.c
>>>> +++ b/src/channel-display-gst.c
>>>> @@ -166,7 +166,7 @@ static void schedule_frame(SpiceGstDecoder *decoder)
>>>>break;
>>>>}
>>>> 
>>>> -if (now < gstframe->frame->mm_time) {
>>>> +if (spice_mmtime_diff(now, gstframe->frame->mm_time) < 0) {
>>>>decoder->timer_id = g_timeout_add(gstframe->frame->mm_time - 
>>>> now,
>>>>  display_frame, decoder);
>>>>} else if (g_queue_get_length(decoder->display_queue) == 1) {
>>>> @@ -511,7 +511,7 @@ static gboolean 
>>>> spice_gst_decoder_queue_frame(VideoDecoder *video_decoder,
>>>>return TRUE;
>>>>}
>>>> 
>>>> -if (frame->mm_time < decoder->last_mm_time) {
>>>> +if (spice_mmtime_diff(frame->mm_time, decoder->last_mm_time) < 0) {
>>>>SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
>>>>" resetting stream",
>>>>frame->mm_time, decoder->last_mm_time);
>>>> diff --git a/src/channel-display-mjpeg.c b/src/channel-display-mjpeg.c
>>>> index ee33b01..3ba098c 100644
>>>> --- a/src/channel-display-mjpeg.c
>>>> +++ b/src/channel-display-mjpeg.c
>>>> @@ -201,7 +201,7 @@ static void mjpeg_decoder_schedule(MJpegDecoder 
>>>> *decoder)
>>>>decoder->cur_frame = NULL;
>>>>do {
>>>>if (frame) {
>>>> -if (time <= frame->mm_time) {
>>>> +if (spice_mmtime_diff(time, frame->mm_time) <= 0) {
>>>>guint32 d = frame->mm_time - time;
>>>>decoder->cur_frame = frame;
>>>>decoder->timer_id = g_timeout_add(d, 
>>>> mjpeg_decoder_decode_frame, decoder);
>>>> @@ -251,7 +251,7 @@ static gboolean mjpeg_decoder_queue_frame(VideoDecoder 
>>>> *video_decoder,
>>>> 
>>>>last_frame = g_queue_peek_tail(decoder->msgq);
>>>>if (last_frame) {
>>>> -if (frame->mm_time < last_frame->mm_time) {
>>>> +if (spice_mmtime_diff(frame->mm_time, last_frame->mm_time) < 0) {
>>>>/* This should really not happen */
>>>>SPICE_DEBUG("new-frame-time < last-frame-time (%u < %u):"
>>>>" resetting stream",
>>>> diff --git a/src/channel-display.c b/src/channel-display.c
>>>> index 3c98d79..06ed18a 100644
>>>> --- a/src/channel-display.c
>>>> +++ b/src/channel-display.c
>>>> @@ -1366,7 +1366,7 @@ static void 
>>>> display_update_stream_report(SpiceDisplayChannel *channel, uint32_t
>>>>}
>>>> 
>>>>if (st->report_num

Re: [Spice-devel] [PATCH spice-gtk] gst-audio: Do not update mmtime without real audio channel

[Christophe de Dinechin]

> On 18 Jul 2017, at 17:59, Christophe de Dinechin <dinec...@redhat.com> wrote:
> 
>> 
>> On 18 Jul 2017, at 17:54, Pavel Grunt <pgr...@redhat.com> wrote:
>> 
>> On Tue, 2017-07-18 at 17:04 +0200, Christophe de Dinechin wrote:
>>> On 14 Jul 2017, at 14:27, Christophe de Dinechin <dinec...@redhat.com> 
>>> wrote:
>>>> 
>>>> This looks better than my fix. Can’t ack right now (I did not build and 
>>>> test
>>>> it yet), but that looks like a reasonable approach
>>>> 
>>>>> On 14 Jul 2017, at 14:24, Pavel Grunt <pgr...@redhat.com> wrote:
>>>>> 
>>>>> This also fixes the huge memore leak reported by Christophe.
>>>>> Steps to reproduce:
>>>>> 1. ./configure --disable-pulse --enable-gstaudio
>>>>> 2. connect to a vm streaming video with no audio playing
>>>>> 3. see the memory grow really fast
>>>>> 
>>>>> It seems to be due to the fact that the "fake audio" channel updates the
>>>>> mmtime
>>>>> in a way that schedules the frames to the future ((unsigned) 0 - delay)
>>>>> and then
>>>>> gstreamer starts to queue the frames (they should be played later)
>>>>> 
>>>>> Pavel
>>>>> 
>>>>> On Fri, 2017-07-14 at 13:19 +0200, Pavel Grunt wrote:
>>>>>> The fake channel has been introduced to get the audio volume by starting
>>>>>> the gstreamer's audio pipeline and querring its volume info (see commit
>>>>>> aa8d044417bbf60685f59163b874ecb4f157c3c9).
>>>>>> 
>>>>>> Hovewer starting the pipeline updates the mmtime as a side effect. This
>>>>>> may cause a (big) delay in displaying a video stream.
>>>>>> 
>>>>>> Because the fake channel is only needed to get the volume info, make
>>>>>> sure to not update the mm-time with it.
>>>>>> 
>>>>>> Reported-by: Christophe de Dinechin <dinec...@redhat.com>
>>>>>> ---
>>>>>> src/spice-gstaudio.c | 11 +++
>>>>>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>>>>> 
>>>>>> diff --git a/src/spice-gstaudio.c b/src/spice-gstaudio.c
>>>>>> index 014c3a5..715f824 100644
>>>>>> --- a/src/spice-gstaudio.c
>>>>>> +++ b/src/spice-gstaudio.c
>>>>>> @@ -38,6 +38,7 @@ struct stream {
>>>>>>   GstElement  *sink;
>>>>>>   guint   rate;
>>>>>>   guint   channels;
>>>>>> +gbooleanfake; /* fake channel just for getting info
>>>>>> about
>>>>>> audio (volume) */
>>>>>> };
>>>>>> 
>>>>>> struct _SpiceGstaudioPrivate {
>>>>>> @@ -264,6 +265,8 @@ static gboolean update_mmtime_timeout_cb(gpointer
>>>>>> data)
>>>>>>   SpiceGstaudioPrivate *p = gstaudio->priv;
>>>>>>   GstQuery *q;
>>>>>> 
>>>>>> +g_return_val_if_fail(!p->playback.fake, TRUE);
>>>>>> +
>>>>>>   q = gst_query_new_latency();
>>>>>>   if (gst_element_query(p->playback.pipe, q)) {
>>>>>>   gboolean live;
>>>>>> @@ -326,7 +329,7 @@ cleanup:
>>>>>>   if (p->playback.pipe)
>>>>>>   gst_element_set_state(p->playback.pipe, GST_STATE_PLAYING);
>>>>>> 
>>>>>> -if (p->mmtime_id == 0) {
>>>>>> +if (!p->playback.fake && p->mmtime_id == 0) {
>>>>>>   update_mmtime_timeout_cb(gstaudio);
>>>>>>   p->mmtime_id = g_timeout_add_seconds(1, update_mmtime_timeout_cb,
>>>>>> gstaudio);
>>>>>>   }
>>>>>> @@ -569,7 +572,6 @@ static gboolean
>>>>>> spice_gstaudio_get_playback_volume_info_finish(SpiceAudio *audio
>>>>>>   GstElement *e;
>>>>>>   gboolean lmute;
>>>>>>   gdouble vol;
>>>>>> -gboolean fake_channel = FALSE;
>>>>>>   GTask *task = G_TASK(res);
>>>>>> 
>>>>>>   g_return_val_if_fail(g_task_is_valid(task, audio), FALSE);
>>>>>> @@ -584,9 +586,9 @@ static gboolean
>>>

Re: [Spice-devel] [PATCH spice-gtk] gst-audio: Do not update mmtime without real audio channel

[Christophe de Dinechin]

> On 18 Jul 2017, at 17:54, Pavel Grunt <pgr...@redhat.com> wrote:
> 
> On Tue, 2017-07-18 at 17:04 +0200, Christophe de Dinechin wrote:
>> On 14 Jul 2017, at 14:27, Christophe de Dinechin <dinec...@redhat.com> wrote:
>>> 
>>> This looks better than my fix. Can’t ack right now (I did not build and test
>>> it yet), but that looks like a reasonable approach
>>> 
>>>> On 14 Jul 2017, at 14:24, Pavel Grunt <pgr...@redhat.com> wrote:
>>>> 
>>>> This also fixes the huge memore leak reported by Christophe.
>>>> Steps to reproduce:
>>>> 1. ./configure --disable-pulse --enable-gstaudio
>>>> 2. connect to a vm streaming video with no audio playing
>>>> 3. see the memory grow really fast
>>>> 
>>>> It seems to be due to the fact that the "fake audio" channel updates the
>>>> mmtime
>>>> in a way that schedules the frames to the future ((unsigned) 0 - delay)
>>>> and then
>>>> gstreamer starts to queue the frames (they should be played later)
>>>> 
>>>> Pavel
>>>> 
>>>> On Fri, 2017-07-14 at 13:19 +0200, Pavel Grunt wrote:
>>>>> The fake channel has been introduced to get the audio volume by starting
>>>>> the gstreamer's audio pipeline and querring its volume info (see commit
>>>>> aa8d044417bbf60685f59163b874ecb4f157c3c9).
>>>>> 
>>>>> Hovewer starting the pipeline updates the mmtime as a side effect. This
>>>>> may cause a (big) delay in displaying a video stream.
>>>>> 
>>>>> Because the fake channel is only needed to get the volume info, make
>>>>> sure to not update the mm-time with it.
>>>>> 
>>>>> Reported-by: Christophe de Dinechin <dinec...@redhat.com>
>>>>> ---
>>>>> src/spice-gstaudio.c | 11 +++
>>>>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>>>> 
>>>>> diff --git a/src/spice-gstaudio.c b/src/spice-gstaudio.c
>>>>> index 014c3a5..715f824 100644
>>>>> --- a/src/spice-gstaudio.c
>>>>> +++ b/src/spice-gstaudio.c
>>>>> @@ -38,6 +38,7 @@ struct stream {
>>>>>   GstElement  *sink;
>>>>>   guint   rate;
>>>>>   guint   channels;
>>>>> +gbooleanfake; /* fake channel just for getting info
>>>>> about
>>>>> audio (volume) */
>>>>> };
>>>>> 
>>>>> struct _SpiceGstaudioPrivate {
>>>>> @@ -264,6 +265,8 @@ static gboolean update_mmtime_timeout_cb(gpointer
>>>>> data)
>>>>>   SpiceGstaudioPrivate *p = gstaudio->priv;
>>>>>   GstQuery *q;
>>>>> 
>>>>> +g_return_val_if_fail(!p->playback.fake, TRUE);
>>>>> +
>>>>>   q = gst_query_new_latency();
>>>>>   if (gst_element_query(p->playback.pipe, q)) {
>>>>>   gboolean live;
>>>>> @@ -326,7 +329,7 @@ cleanup:
>>>>>   if (p->playback.pipe)
>>>>>   gst_element_set_state(p->playback.pipe, GST_STATE_PLAYING);
>>>>> 
>>>>> -if (p->mmtime_id == 0) {
>>>>> +if (!p->playback.fake && p->mmtime_id == 0) {
>>>>>   update_mmtime_timeout_cb(gstaudio);
>>>>>   p->mmtime_id = g_timeout_add_seconds(1, update_mmtime_timeout_cb,
>>>>> gstaudio);
>>>>>   }
>>>>> @@ -569,7 +572,6 @@ static gboolean
>>>>> spice_gstaudio_get_playback_volume_info_finish(SpiceAudio *audio
>>>>>   GstElement *e;
>>>>>   gboolean lmute;
>>>>>   gdouble vol;
>>>>> -gboolean fake_channel = FALSE;
>>>>>   GTask *task = G_TASK(res);
>>>>> 
>>>>>   g_return_val_if_fail(g_task_is_valid(task, audio), FALSE);
>>>>> @@ -584,9 +586,9 @@ static gboolean
>>>>> spice_gstaudio_get_playback_volume_info_finish(SpiceAudio *audio
>>>>> 
>>>>>   if (p->playback.sink == NULL || p->playback.channels == 0) {
>>>>>   SPICE_DEBUG("PlaybackChannel not created yet, force start");
>>>>> +p->playback.fake = TRUE;
>>>>>   /* In order to get system volume, we start the pipeline */
>>>>>   playback_start(NULL,

Re: [Spice-devel] [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code

[Christophe de Dinechin]

> On 19 Jul 2017, at 19:21, Frediano Ziglio <fzig...@redhat.com> wrote:
> 
>> 
>> On Wed, Jul 19, 2017 at 08:03:49AM -0400, Frediano Ziglio wrote:
>>>> 
>>>> On Wed, Jul 19, 2017 at 12:09:23PM +0200, Christophe de Dinechin wrote:
>>>>> 
>>>>>> On 19 Jul 2017, at 11:21, Christophe Fergeau <cferg...@redhat.com>
>>>>>> wrote:
>>>>>> 
>>>>>> On Wed, Jul 19, 2017 at 10:23:30AM +0200, Christophe de Dinechin
>>>>>> wrote:
>>>>>>> 
>>>>>>>> On 18 Jul 2017, at 17:28, Christophe Fergeau <cferg...@redhat.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> On Mon, Jul 17, 2017 at 11:01:22AM +0100, Frediano Ziglio wrote:
>>>>>>>>> Remove CxImage linking.
>>>>>>>>> Support Windows BMP format.
>>>>>>>> 
>>>>>>>> Too bad there is no small/maintained library which would do that
>>>>>>>> for us
>>>>>>>> :-/ From a quick glance, looks ok.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> +static inline size_t compute_dib_stride(unsigned width, unsigned
>>>>>>>>> bit_count)
>>>>>>>> 
>>>>>>>> Can you use full type names, unsigned int?
>>>>>>> 
>>>>>>> No. Really, no ;-) Otherwise, for consistency, you should replace
>>>>>>> ‘int’
>>>>>>> with ‘signed int’,
>>>>>> 
>>>>>> The way I see it, 'signed'/'unsigned' are type modifiers, 'int' is an
>>>>>> actual type name.
>>>>> 
>>>>> Yes. But ‘long’ is not. It is also a modifier. So why allow “long” or
>>>>> “short" but not “unsigned”?
>>>>> Or are you also writing “long int” and “short int”?
>>>> 
>>>> long/short are enough to make the storage size of the integer obvious,
>>>> even if you don't know that long means long int.
>>>> "unsigned" does not make this obvious unless you know that "unsigned"
>>>> means "unsigned int"
>>>> 
>>> 
>>> Section 6.7.2 of C99 standard specified "unsigned" as type.
>>> The fact you are not familiar with this is an opinion I don't
>>> personally share. "long" does not specify a type as "unsigned"
>>> doesn't.
>>> 
>> 
>> [...]
>> 
>>> 
>>> So let's write "long int" for anything. "unsigned" is not less typing,
>>> it's a type specified by the language.
>> 
>> I never said "unsigned" is not standard compliant, so I don't know why
>> you keep coming back to that.
>> I previously said that just because something is standard-compliant does
>> not mean it's a good idea to do it, [insert your favourite obfuscated C
>> contest example here].
>> 
>> In this particular case, since you feel strongly about it, feel free to
>> ignore my comment, but I'll nonetheless keep thinking it makes things
>> less readable ;)
>> 
>> Christophe
>> 
> 
> I moved to "unsigned int" 2 versions ago.

It was courteous of you.

> 
> But still think that is a useful discussion. But honestly I think
> in this case the readability is quite an opinion and for me
> unsigned is like long, perfectly readable and I saw lot of code
> using just unsigned.

It is useful on two levels:

a) Because I personally feel ‘unsigned int’ less readable and less
consistent with the common usage for.’long’ or ‘short’.

b) To discuss the matter of debating style preferences in code reviews,
notably for new code and new languages.

In that case, we have C++ code, where my experience tells me that
‘unsigned’ is by far more common (as is camel-case, for example).

If we start considering that some C programmer may not know that
‘unsigned’ means ‘unsigned int’, what happens the first time someone
introduces ‘auto’ or ‘for (a : b) in C++ code, or _Generic in C code?

> 
> Frediano
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org <mailto:Spice-devel@lists.freedesktop.org>
> https://lists.freedesktop.org/mailman/listinfo/spice-devel 
> <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] [vdagent-win PATCH v4 3/5] Write code to decode PNG format

[Christophe de Dinechin]

> On 18 Jul 2017, at 17:54, Christophe Fergeau  wrote:
> 
> On Mon, Jul 17, 2017 at 09:54:04AM +0100, Frediano Ziglio wrote:
>> Signed-off-by: Frediano Ziglio 
>> ---
>> Makefile.am  |   6 +-
>> configure.ac |   3 +
>> vdagent/image.cpp|   8 +-
>> vdagent/imagepng.cpp | 244 
>> +++
>> vdagent/imagepng.h   |  25 ++
>> 5 files changed, 277 insertions(+), 9 deletions(-)
>> create mode 100644 vdagent/imagepng.cpp
>> create mode 100644 vdagent/imagepng.h
>> 
>> diff --git a/Makefile.am b/Makefile.am
>> index b35dd57..175d8f7 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -23,8 +23,8 @@ LIBS = -lversion
>> 
>> bin_PROGRAMS = vdagent vdservice
>> 
>> -vdagent_LDADD = -lwtsapi32 -lgdi32 vdagent_rc.$(OBJEXT)
>> -vdagent_CXXFLAGS = $(AM_CXXFLAGS)
>> +vdagent_LDADD = $(LIBPNG_LIBS) $(ZLIB_LIBS) -lwtsapi32 -lgdi32 
>> vdagent_rc.$(OBJEXT)
>> +vdagent_CXXFLAGS = $(AM_CXXFLAGS) $(LIBPNG_CFLAGS)
>> vdagent_LDFLAGS = $(AM_LDFLAGS) -Wl,--subsystem,windows
>> vdagent_SOURCES =\
>>  common/vdcommon.cpp \
>> @@ -44,6 +44,8 @@ vdagent_SOURCES =  \
>>  vdagent/as_user.h   \
>>  vdagent/image.cpp   \
>>  vdagent/image.h \
>> +vdagent/imagepng.cpp\
>> +vdagent/imagepng.h  \
>>  $(NULL)
>> 
>> vdagent_rc.$(OBJEXT): vdagent/vdagent.rc
>> diff --git a/configure.ac b/configure.ac
>> index 4eac4b4..bb33075 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -101,6 +101,9 @@ dnl 
>> ---
>> dnl - Check library dependencies
>> dnl 
>> ---
>> 
>> +PKG_CHECK_MODULES(LIBPNG, [libpng])
>> +PKG_CHECK_MODULES(ZLIB, [zlib])
>> +
>> dnl 
>> ---
>> dnl - Makefiles, etc.
>> dnl 
>> ---
>> diff --git a/vdagent/image.cpp b/vdagent/image.cpp
>> index b32da6f..c968217 100644
>> --- a/vdagent/image.cpp
>> +++ b/vdagent/image.cpp
>> @@ -21,9 +21,9 @@
>> 
>> #include "vdcommon.h"
>> #include "image.h"
>> +#include "imagepng.h"
>> 
>> ImageCoder *create_bitmap_coder();
>> -ImageCoder *create_png_coder();
>> 
>> static ImageCoder *get_coder(uint32_t vdagent_type)
>> {
>> @@ -172,9 +172,3 @@ ImageCoder *create_bitmap_coder()
>> {
>> return new BitmapCoder();
>> }
>> -
>> -// TODO
>> -ImageCoder *create_png_coder()
>> -{
>> -return NULL;
>> -}
>> diff --git a/vdagent/imagepng.cpp b/vdagent/imagepng.cpp
>> new file mode 100644
>> index 000..19d9efc
>> --- /dev/null
>> +++ b/vdagent/imagepng.cpp
>> @@ -0,0 +1,244 @@
>> +/*
>> +   Copyright (C) 2017 Red Hat, Inc.
>> +
>> +   This program is free software; you can redistribute it and/or
>> +   modify it under the terms of the GNU General Public License as
>> +   published by the Free Software Foundation; either version 2 of
>> +   the License, or (at your option) any later version.
>> +
>> +   This program 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 General Public License for more details.
>> +
>> +   You should have received a copy of the GNU General Public License
>> +   along with this program.  If not, see .
>> +*/
>> +
>> +#include "vdcommon.h"
>> +
>> +#include 
>> +#include 
>> +
>> +#include "imagepng.h"
>> +
>> +class PngCoder: public ImageCoder
>> +{
>> +public:
>> +PngCoder() {};
>> +size_t get_dib_size(const uint8_t *data, size_t size);
>> +void get_dib_data(uint8_t *dib, const uint8_t *data, size_t size);
>> +uint8_t *from_bitmap(const BITMAPINFO& info, const void *bits, long 
>> );
>> +private:
>> +size_t convert_to_dib(uint8_t *out_buf, const uint8_t *data, size_t 
>> size);
>> +};
>> +
>> +struct BufferIo {
>> +uint8_t *buf;
>> +uint32_t pos, size;
>> +};
>> +
>> +static void read_from_bufio(png_structp png, png_bytep out, png_size_t size)
>> +{
>> +BufferIo& io(*(BufferIo*)png_get_io_ptr(png));

As long as you do a cast form a pointer, I would rather use a pointer to 
BufferIo here.

>> +if (io.pos + size >= io.size)
>> +png_error(png, "read past end");
>> +memcpy(out, io.buf+io.pos, size);

This memcpy should be in ‘else’, unless png_error interrupts the flow of 
control (I saw a png_jumpbuf below that frightens me).

>> +io.pos += size;
>> +}
>> +
>> +size_t PngCoder::get_dib_size(const uint8_t *data, size_t size)
>> +{
>> +return convert_to_dib(NULL, data, size);
>> +}
>> +
>> +typedef void line_fixup_t(uint8_t *line, unsigned width);
>> +
>> +static void line_fixup_none(uint8_t *line, unsigned 

Re: [Spice-devel] [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code

[Christophe de Dinechin]

> On 18 Jul 2017, at 17:28, Christophe Fergeau  wrote:
> 
> On Mon, Jul 17, 2017 at 11:01:22AM +0100, Frediano Ziglio wrote:
>> Remove CxImage linking.
>> Support Windows BMP format.
> 
> Too bad there is no small/maintained library which would do that for us
> :-/ From a quick glance, looks ok.
> 
> 
>> 
>> +static inline size_t compute_dib_stride(unsigned width, unsigned bit_count)
> 
> Can you use full type names, unsigned int?

No. Really, no ;-) Otherwise, for consistency, you should replace ‘int’ with 
‘signed int’, specify whether char are signed or unsigned, and use ’signed long 
int’ instead of ‘long’. And while we are at it, decide whether “int long 
unsigned typedef ulong” is evil, or whether it’s the epitome of C syntactic 
elegance.


Christophe 
> 
> Christophe
> 
>> +{
>> +return ((width * bit_count + 31u) & ~31u) / 8u;
>> +}
>> +
>> /**
>>  * Returns image to put in the clipboard.
>>  *
>> -- 
>> 2.13.3
>> 
>> ___
>> 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

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

Re: [Spice-devel] [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code

[Christophe de Dinechin]

> On 20 Jul 2017, at 11:23, Christophe Fergeau <cferg...@redhat.com> wrote:
> 
> On Thu, Jul 20, 2017 at 09:42:26AM +0200, Christophe de Dinechin wrote:
>>> I moved to "unsigned int" 2 versions ago.
>> 
>> It was courteous of you.
> 
> Yup, thanks, did not take a look at the newer iterations yet.
> 
>> 
>>> 
>>> But still think that is a useful discussion. But honestly I think
>>> in this case the readability is quite an opinion and for me
>>> unsigned is like long, perfectly readable and I saw lot of code
>>> using just unsigned.
>> 
>> It is useful on two levels:
>> 
>> a) Because I personally feel ‘unsigned int’ less readable and less
>> consistent with the common usage for.’long’ or ‘short’.
> 
> Talking about consistency, should why are you using 'int' rather than
> 'signed' if you prefer using 'unsigned’?

For the same reason that I prefer ‘unsigned’ over ‘unsigned int’ : because
it is the shortest way to express the given type. Remember ‘WET’,
“We Enjoy Typing” ? :-)

> Another way of seeing
> consistency is:
> 
> unsigned long
> unsigned short
> unsigned int

Unsigned long and unsigned short cannot be written in any other way
without a typedef. But many developers have typedefs such as
ulong or ushort to avoid what they see as an inconsistency, having
types that require two words when the vast majority of types require
only one (see below one implication for C++).

> 
> You've got the unsigned modifier, and then something giving a hint at
> the storage size.
> 
> Similarly, you have:
> 
> long
> short
> int
> 
> and you know these usually are signed.

No, they are always signed. Only char is possibly signed or unsigned, AFAIR.
See 
https://stackoverflow.com/questions/2054939/is-char-signed-or-unsigned-by-default.

> 
>> 
>> b) To discuss the matter of debating style preferences in code reviews,
>> notably for new code and new languages.
>> 
>> In that case, we have C++ code, where my experience tells me that
>> ‘unsigned’ is by far more common (as is camel-case, for example).
>> 
>> If we start considering that some C programmer may not know that
>> ‘unsigned’ means ‘unsigned int’, what happens the first time someone
>> introduces ‘auto’ or ‘for (a : b) in C++ code, or _Generic in C code?
> 
> To reuse your numbers, the usage of unsigned VS unsigned int in arch/ in
> the kernel was 90%/10% or even less than that. So yes, it's not unlikely
> that someone will never have came across "unsigned", or forgot what it
> means, …

Are you saying that since the usage ratio in the Linux kernel is 90%/10%,
it is likely that regular C developers don’t know what ‘unsigned’ means?
I disagree, ‘unsigned’ is not an obscure C feature. A developer who does not
know what ‘unsigned’ means needs to learn it.

> _Generic has no trivial equivalent for C code contrary to
> "unsigned". Your C++ examples being C++ and not C, I would care less
> about C programmers not familiar with C++ ;)

The code under review is C++, isn’t it? C++ users are even more
wary of two-word type names than C users. There are syntactic constructs
in C++ that require a one-word name, notably the new constructor-style
syntax for casts:

% cat /tmp/glop.cpp
int long unsigned typedef ulong;

unsigned ok2 = (unsigned) 1;
unsigned ok1 = unsigned(1);
ulong ok3 = (ulong) 1;
ulong ok4 = ulong(1);
unsigned long ok5 = (unsigned long) 1;
unsigned long bad = unsigned long (1);
ddd@ptitpuce[master] Chapter9> c++ -c /tmp/glop.cpp
/tmp/glop.cpp:8:30: error: expected '(' for function-style cast or type
  construction
unsigned long bad = unsigned long (1);
 ^
1 error generated.

This is one of the reasons for this preference for ‘unsigned’ of all
serious C++ developers that I know of (that may be a possible reason
Frediano unconsciously started with ‘unsigned’ in C++ code):


I’m not sure the discussion is very productive. I only answered because
I thought there was a factual error about int being ‘usually’ signed
and because I thought it was worth explaining the C++ preference for
single-word type names. That being said, I am not sure I can convince
you, so we’ll probably agree to disagree on this one ;-)


Cheers,
Christophe

> 
> Christophe
> ___
> 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] Proposal: review branches (was Re: [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code)

[Christophe de Dinechin]

> On 24 Jul 2017, at 16:06, Marc-André Lureau  
> wrote:
> 
> Hi
> 
> - Original Message -
>>> 
 On 21 Jul 2017, at 12:41, Frediano Ziglio  wrote:
 
> 
> On Fri, Jul 21, 2017 at 06:18:49AM -0400, Frediano Ziglio wrote:
>> Beside that I wonder why I had to wait 8 months for these reviews,
>> not counting the time to decide to rewrite this part of code
>> (with all the wasted time trying to not do it) and the time we
>> waited to fix a known bug which is also a regression (image copy
>> paste are not working) and potentially a security risk (the library
>> versions used contain security bugs but actually the code is disabled).
>> Looks like that if a Red Hat client is not pushing for a fix
>> solutions are not that important.
> 
> People can be busy with other things, and patches can fall through the
> cracks, it's ok to send a 'ping' message once in a while to bring a
> patch series  back to people's attention.
> 
> Christophe
> 
 
 I'm really getting tired of this reply..
>>> 
>>> Hmmm, maybe we can do a few things to reduce that problem.
>>> It would be nice if we had a way to get back to unreviewed patches
>>> without having to browse through the mailing list.
>>> 
>>> Also, as a newbie, I must say I often spend quite some time finding
>>> the base for a patch, which is a shame, because that’s a problem
>>> that git URLs solve quite nicely. The problem is amplified by the
>>> fact that we have multiple components, and patches sometimes
>>> don’t really specify which component they apply to.
>>> 
>>> So maybe we can fix the two problems with one stone. What about
>>> 
>>> 1. Pushing branches for review under a consistent name, e.g. something
>>> like ‘review/c3d/recorder’
>>> 
> 
> You forgot to say that you mean 'pushing in upstream official repo’.

No, in some repository shared by the team (at large), so that we can, at a 
glance, look at what has not been reviewed yet.

> This is not how 'distributed' is supposed to work imho. If every contributor 
> should start pushing is branch, and leave it outdated for ages..

The problem of outdated patches is what we have today, see Frediano’s message 
that started the thread.

> What are the rules about cleaning up those old personal branches? Who should 
> be allowed to push, when etc? no, thanks, use git

How is using git URLs not “using git”?

> and there are plenty of public places you can push your work.

So plenty of places, but by no means a shared one? The point is that we need a 
shared one, to be able to view pending reviews at a glance.

> Then you can use the mailing list to announce it, or to send your patches for 
> review.

Last time I shared a private link as an RFC, you told me this was not the right 
way to do things. Which is why I am now suggesting we also keep the mail patch.


> 
>>> 2. Adding the git URL in the patch, e.g.
>>> https://cgit.freedesktop.org/spice/spice-gtk/log/?h=review/c3d/recorder 
>>> .
>>> 
> 
> That you can already do in a mail, although such url tends to become obsolete 
> pretty quickly. patches series are better archived.

It gets obsolete even faster if you remove the branch I push for illustration 
seconds after I push it ;-)

> If necessary, a cover-letter should say on which commit the series applies. 
> There are tools like patchew that may also help. 

My point is that 1) this is not the case today, and 2) a git link is the best 
way to summarize the history (faster and more reliable than  a cover letter)

> 
>>> 3. Once the patch has been committed, simply do a ‘git push freedesktop
>>> :review/c3d/recorder’
>>> to delete the branch.
> 
> This is extra burden, and will leave broken links

A broken link is useful information. It means “this work has been merged”. As 
for the burden, it’s totally negligible relative to figuring out today if a 
specific patch has been merged.

> 
>>> I see several benefits to doing this:
>>> 
>>> 1. We always know exactly which component and branch is being patched
>>> 
> 
> As long as contributor keep pinging or resending his series, this is already 
> the case.

As Frediano said at the beginning of the series, “I’m tired of hearing this 
reply”.

> 
> A series that is no longer being proposed is basically considered abandoned. 
> I think that rule of thumb works fine in practice.

Some of us disagree.


> 
>>> 2. When you work on branch, a daily “git fetch” will fetch all the new
>>> “review”
>>> branches, so a simple git branch -a will show you what needs to be
>>> reviewed.
> 
> As a developer or as a maintainer, you are not often interested by the 
> various iterations of a work. It's enough to be on CC of a series to review.

If you are not interested, don’t look at the ‘review’ branches then. Where’s 
the problem?

> Eventually, the contributor can send a WIP 

Re: [Spice-devel] Proposal: review branches (was Re: [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code)

[Christophe de Dinechin]

> On 25 Jul 2017, at 12:36, Christophe Fergeau <cferg...@redhat.com> wrote:
> 
> On Tue, Jul 25, 2017 at 12:23:34PM +0200, Christophe de Dinechin wrote:
>>> and there are plenty of public places you can push your work.
>> 
>> So plenty of places, but by no means a shared one? The point is that
>> we need a shared one, to be able to view pending reviews at a glance.
> 
> Note that "we need a way to easily view pending reviews" does not imply
> "this has to be done through review/ branches in a shared repository”

No, it does not. I’m just pointing out one possible way to do it while 
maintaining
the mail-based process that some people here seem to love.

> 
> 
>>> If necessary, a cover-letter should say on which commit the series applies. 
>>> There are tools like patchew that may also help. 
>> 
>> My point is that 1) this is not the case today, and 2) a git link is
>> the best way to summarize the history (faster and more reliable than
>> a cover letter)
> 
> A git branch won't tell you the changes between different versions of
> the same series.

Just like a single mail won’t tell you the changes between this patch and
the previous one. You have to look at the history to find it. As an aside,
git-publish uses tags to preserve the previous versions of a patch in the
git history.


> You can use -v1, -v2 suffixes, but then you are keeping
> obsolete stuff around.

You are not keeping obsolete stuff around, you are keeping a history.
A mailing list is not a better way to record the history of changes than git 
itself.
But at least, you can cleanup branches once the patch is merged (knowing
that the actual history of the patch is recorded in the mail should we need it).
With patches, it’s much harder to look at an e-mail and say “that was merged”.

So no, I don’t think you’d keep obsolete stuff around. You’d keep
“not yet reviewed stuff” around, which is a feature, not a bug.


> And then, a diff between 2 such branches is not
> the best way of summarizing what changed (we would not need commit logs
> if a diff was expressive enough).

I don’t understand what you are saying here.


> And a cover letter usually contains more than just history summary, so still 
> useful ;)

I do not advocate we don’t send patch or a cover letter, I advocate that we send
a git URL along with the patch (or any other practical way to track if that 
thing
was reviewed and actioned upon).


> 
> 
>>>>> I see several benefits to doing this:
>>>>> 
>>>>> 1. We always know exactly which component and branch is being patched
>>>>> 
>>> 
>>> As long as contributor keep pinging or resending his series, this is 
>>> already the case.
>> 
>> As Frediano said at the beginning of the series, “I’m tired of hearing this 
>> reply”.
> 
> And this is not an actionable answer... My perception is that there
> rarely are 'ping' on old series. Does this mean we are doing a good job
> at reviews?

I think that we (but not I) are doing an OK job at reviews, but we apparently 
drop
some reviews, e.g. because they were too complex, or did not represent the
priority of the time.

That being said, I observe that there are better ways to track WIP than pure 
mail.
Redmine, JIRA, pull requests, whatever. All well known solutions to the problems
we complain about.

As an aside, these tools typically solve many other problems too, like being 
able to
record things to be done *before* there is a patch for them, or CI, or 
priorities, etc.
Frankly, Bugzilla + Mail brings me back a good 15 years ago or something.

I don’t care much about which tool we use. I do mind that we have none.


> (I doubt it or we would not have this conversation) Does
> this mean patch senders do not want to do that? Why? Does this mean it's
> done a lot, but to no avail? All I'm reading is "I'm not happy with how
> things work", with nothing specific.

It’s funny, because
a) I never said I was unhappy, and
b) I gave a very simple, very specific suggestion for action, which was to add a
URL to a branch with the name review// on freedesktop.org to the
cover letter or patch description.

So how you turn that into “I’m not happy with how things work with nothing 
specific”
is a bit beyond my understanding.

As a new team member, I’m find it unnecessarily difficult to know what a
given patch applies to, or to reconstruct code that actually compiles for 
testing,
or to see how it was tested before I look at the code, etc. I noticed that the 
patch
URL would *also* solve that problem. That’s about it.

As an aside, I find it strange to have private repos of half a dozen team 
members
in my history already, instead of a shared repo for things we are working on.


> 
>>> Eventually, the contr

Re: [Spice-devel] Proposal: review branches (was Re: [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code)

[Christophe de Dinechin]

> On 26 Jul 2017, at 12:19, Frediano Ziglio <fzig...@redhat.com> wrote:
> 
>>> 
>>> On 25 Jul 2017, at 19:37, Christophe Fergeau <cferg...@redhat.com> wrote:
>>> 
>>> On Tue, Jul 25, 2017 at 02:26:36PM +0200, Christophe de Dinechin wrote:
>>>>>>> As long as contributor keep pinging or resending his series, this is
>>>>>>> already the case.
>>>>>> 
>>>>>> As Frediano said at the beginning of the series, “I’m tired of hearing
>>>>>> this reply”.
>>>>> 
>>>>> And this is not an actionable answer... My perception is that there
>>>>> rarely are 'ping' on old series. Does this mean we are doing a good job
>>>>> at reviews?
>>>> 
>>>> I think that we (but not I) are doing an OK job at reviews, but we
>>>> apparently drop
>>>> some reviews, e.g. because they were too complex, or did not represent the
>>>> priority of the time.
>>>> 
>>>> That being said, I observe that there are better ways to track WIP than
>>>> pure mail.
>>>> Redmine, JIRA, pull requests, whatever. All well known solutions to the
>>>> problems
>>>> we complain about.
>>>> 
>>>> As an aside, these tools typically solve many other problems too, like
>>>> being able to
>>>> record things to be done *before* there is a patch for them, or CI, or
>>>> priorities, etc.
>>>> Frankly, Bugzilla + Mail brings me back a good 15 years ago or something.
>>>> 
>>>> I don’t care much about which tool we use. I do mind that we have none.
>>> 
>>> The patch submitter's mind who sends ping when the series gets too old
>>> can be seen as such a tool, with the added benefit that they know if the
>>> series is still relevant, they can solve complex conflicts when
>>> rebasing, ... :)
>>> 
>>>>> (I doubt it or we would not have this conversation) Does
>>>>> this mean patch senders do not want to do that? Why? Does this mean it's
>>>>> done a lot, but to no avail? All I'm reading is "I'm not happy with how
>>>>> things work", with nothing specific.
>>>> 
>>>> It’s funny, because
>>>> a) I never said I was unhappy, and
>>>> b) I gave a very simple, very specific suggestion for action, which was to
>>>> add a
>>>> URL to a branch with the name review// on freedesktop.org
>>>> to the
>>>> cover letter or patch description.
>>>> 
>>>> So how you turn that into “I’m not happy with how things work with nothing
>>>> specific”
>>>> is a bit beyond my understanding.
>>> 
>>> The quote (from you) on top of this part of my answer was
>>> « As Frediano said at the beginning of the series, “I’m tired of hearing
>>> this reply”. »
>>> I was specifically referring to that, which is non-specific, and which I
>>> interpret as unhappiness. I'll blame written media for any
>>> misinterpretation here :)
>> 
>> The good thing about written media is that we can go back for the full
>> context, namely:
>> 
>>> 
>>>>>> I see several benefits to doing this:
>>>>>> 
>>>>>> 1. We always know exactly which component and branch is being patched
>>>>>> 
>>>> 
>>>> As long as contributor keep pinging or resending his series, this is
>>>> already the case.
>>> 
>>> As Frediano said at the beginning of the series, “I’m tired of hearing this
>>> reply”.
>> 
>> I was simply quoting Frediano to indicate that he had already responded.
>> 
>> Ping is not a solution, it is a symptom of the problem. The problem being
>> forgotten reviews.
>> 
>> Also, ping is a response for forgotten reviews, how does it help figuring out
>> the
>> origin repository? Read again what I wrote, that’s clearly what I am talking
>> about.
>> 
>> So I’m sorry, but it looks like you are giving a canned response, “ping”,
>> that not
>> only ignores Frediano’s frustration with having to ping, but also ignores the
>> problem
>> I’m bringing up as being also solved by git URLs, namely the difficulty to
>> find
>> which repository a patch applies to. Hence my reusing the “I’m tired of”
>> formulation :-)
>> 
>> 
>>>>> If yes, what is it? Patch reviews not being d

Re: [Spice-devel] Proposal: review branches (was Re: [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code)

[Christophe de Dinechin]

> On 26 Jul 2017, at 11:23, Marc-André Lureau  
> wrote:
> 
> Hi
> 
> - Original Message -
>> Now, any objection to
>> 
>> 1. Recommending that we use git URLs in patches?
> 
> If that may help, but as Christophe said, this may be overkill for small 
> series. Let's not make it a rule.
> 
>> 2. Having a shared location for branches under review?
> 
> This is really contrary to the distributed nature of git.

If that was true, why would the inventor of git, Linus Torvalds, use a public 
shared place like kernel.org?

Git gives you the freedom to have multiple repos and sync them easily. It does 
not place a restriction that you can’t have a shared one for a team.

> 
> Add a remote remote repo if you are interested by tracking someone else work, 
> it works just as well.

No, it does not. It means you need to git fetch multiple places. It’s 
complicated enough that there are 17 repositories in the spice project. For one 
of them I have 12 remotes already. That does not scale well.

> 
> Imho, we could benefit using a system tracking patch series state from the 
> mailing list, such as patchew. But it would probably need some work to fit 
> Spice needs.

We would benefit from that, yes. But that’s another issue entirely.

> ___
> 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] [vdagent-win PATCH] Do not use dash in rpm version

[Christophe de Dinechin]

> On 26 Jul 2017, at 17:03, Frediano Ziglio  wrote:
> 
> RPM does not allow dash in version string.
> Remove everything after the dash (which should be the "dirty"
> git version).
> This make easier to run "make dist" followed by rpmbuild.
> 
> Signed-off-by: Frediano Ziglio 
> ---
> configure.ac| 2 ++
> mingw-spice-vdagent.spec.in | 6 +++---
> 2 files changed, 5 insertions(+), 3 deletions(-)
> 
> Maybe I should use sed 's,-,.,g' to just replace
> all dashes with dots ?

Yes, I think it is better to not remove the ‘dirty’ from the name.

You can use _ as Pavel suggested too.

> 
> diff --git a/configure.ac b/configure.ac
> index bb33075..dc75c25 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -38,6 +38,8 @@ AC_DEFINE_UNQUOTED([RC_PRODUCTVERSION_STR], 
> "$RC_PRODUCTVERSION", [Resource prod
> AC_DEFINE_UNQUOTED([RC_PRODUCTVERSION], [$RC_PRODUCTVERSION], [Resource 
> product version])
> BUILD_YEAR=`date +%Y`
> AC_DEFINE_UNQUOTED([BUILD_YEAR], "$BUILD_YEAR", [Build year])
> +RPM_VERSION=`echo $PACKAGE_VERSION | sed 's,-.*,,’`



> +AC_SUBST([RPM_VERSION])
> 
> # Check for programs
> AC_PROG_CC
> diff --git a/mingw-spice-vdagent.spec.in b/mingw-spice-vdagent.spec.in
> index d25ea31..d129a7b 100644
> --- a/mingw-spice-vdagent.spec.in
> +++ b/mingw-spice-vdagent.spec.in
> @@ -16,13 +16,13 @@
> %endif
> 
> Name:   mingw-spice-vdagent
> -Version:@VERSION@
> +Version:@RPM_VERSION@
> Release:1%{?dist}%{?extra_release}
> Summary:MinGW Windows SPICE guest agent
> 
> License:GPLv2+
> URL:https://www.spice-space.org/
> -Source0:vdagent-win-%{version}%{?_version_suffix}.tar.xz
> +Source0:vdagent-win-@VERSION@%{?_version_suffix}.tar.xz
> 
> BuildRequires:  mingw32-filesystem >= 23
> BuildRequires:  mingw64-filesystem >= 23
> @@ -84,7 +84,7 @@ Features:
>   session and the client
> 
> %prep
> -%setup -q -n vdagent-win-%{version}%{?_version_suffix}
> +%setup -q -n vdagent-win-@VERSION@%{?_version_suffix}
> 
> %{mingw_debug_package}
> 
> -- 
> 2.13.3
> 
> ___
> 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] [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code

[Christophe de Dinechin]

> On 27 Jul 2017, at 15:27, Frediano Ziglio  wrote:
> 
> On 27 Jul 2017, at 15:07, Frediano Ziglio  wrote:
> 
> On 27 Jul 2017, at 12:39, Christophe Fergeau  wrote:
> 
> On Thu, Jul 27, 2017 at 11:54:08AM +0200, Victor Toso wrote:
> On Mon, Jul 24, 2017 at 10:47:34AM -0400, Frediano Ziglio wrote:
> Not really familiar with GitLab merge requests but on GitHub they
> remain open till closed so this would help with old ones.
> The big change on moving to full PR is the way of commenting patches.
> Unless PR are just used for tracking and are replicated to ML but
> maybe is hard to keep them consistent. I think is possible to configure
> PRs to send changes to ML. This would make the history persistent on
> the ML.
> 
> Could we try for a period and see how does it go?
> 
> +1, but how should we approach that? I think we need to move from
> freedesktop to either gitlab or github first otherwise we can get
> confused on what's going on.
> 
> 
> Just to be sure, you are both suggesting switching to pull requests, and
> doing the reviews in gitlab web UI?
> 
> Not me. Reviewing by mail is fine with me.
> 
> Actually, Im concerned that if we switch to PR/MR, then some comments
> will end up being made only there, which is why I asked if there was a
> way to forward these comments to the mailing list. I believe this
> is possible from the group administration (its certainly possible
> for individual accounts on gitlab).
> 
> 
> The initial problem is that some reviews are not done in a timely
> manner. Being able to easily get a list of pending reviews was brought
> forward as a potential solution to this problem, and apparently, you
> both think that switching from email based reviews to a web based review
> system would help in getting more reviews faster? (iow, it would make
> you more efficient at reviewing code, and you vastly prefer that over
> email).
> 
> No, that’s not correct (at least for me). The review itself can happen over 
> mail,
> what I find inefficient is:
> 
> a) to get the list of things to review, and
> b) to get a working version of the code after patching
> 
> For a), email is good to notify you of recent reviews posted. But searching
> through e-mail for unreviewed stuff is not easy. Do you have a good trick for 
> that?
> 
> For b), Im not talking about git am. You may not realize that just
> figuring out which of our 17 repositories (not including personal
> ones) some particular patch applies to is not always obvious.
> 
> Im pretty sure this is not so much of a problem when you have worked
> longer on the project, so I am bringing that up precisely because
> Im still fresh enough to remember this being an issue.
> 
> 
> 
> I'm not necessarily opposed to trying things out, I'm just trying to get
> a clear view of what we are expecting to get out of the change.
> 
> First things first, if we want to try MR/PR, we should switch to gitlab
> as the primary. I understand there was a desire to do that also because
> freedesktop user creation was slow.
> 
> Would this be a valid first step?
> 
> 
> Christophe
> There's already https://gitlab.com/spice/spice
> 
> Yes, but it’s a clone of freedesktop instead of the other way round. So as I 
> pointed out in an earlier email, if we enable merge requests there, we may 
> end up with merge commits, and then a push from freeedesktop will run into 
> trouble.
> 
> So if we want to try MR on gitlab.com, then we need gitlab to be primary and 
> freedesktop to be the mirror, I believe.
> 
> 
> Christophe
> Not necessary you have to merge using the button, you can do it manually.

So is there a way to allow merge requests but disallow the button? There is in 
JIRA, not sure about Gitlab.

> 
> Frediano
> 
> OT: Christophe can you setup mail to send text format instead of html?

It’s funny. I can, but you are the one sending in HTML, and my configuration, 
by default, replies to HTML mails in HTML.

Chirstophe


> ___
> 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] [PATCH spice-server] README: Fix typo (dependancies -> dependencies)

[Christophe de Dinechin]

> On 27 Jul 2017, at 15:25, Frediano Ziglio <fzig...@redhat.com> wrote:
> 
> Signed-off-by: Frediano Ziglio <fzig...@redhat.com>
> ---
> README | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/README b/README
> index dea43444..45fbe89c 100644
> --- a/README
> +++ b/README
> @@ -24,7 +24,7 @@ Or to install into a private user specific location
>   make
>   make install
> 
> -The following mandatory dependancies are required in order to
> +The following mandatory dependencies are required in order to
> build SPICE
> 
> Spice protocol >= 0.9.0
> @@ -34,7 +34,7 @@ build SPICE
> zlib
> Cyrus-SASL
> 
> -The following optional dependancies increase the available
> +The following optional dependencies increase the available
> functionality
> 
> GE Gui >= 0.6.0,  < 0.7.0   (GUI app support)
> -- 
> 2.13.3
> 

Acked by: Christophe de Dinechin <dinec...@redhat.com>


Related to discussion on URLs, and because of the [PATCH spice-server]: 
Shouldn’t we rename the spice repo as spice-server, and have some top-level 
spice repository that would have all the others as submodules?


> ___
> 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] [PATCH spice-server] README: Update required protocol version

[Christophe de Dinechin]

> On 27 Jul 2017, at 15:25, Frediano Ziglio  wrote:
> 
> Signed-off-by: Frediano Ziglio 
> ---
> README | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/README b/README
> index 45fbe89c..0fd6f071 100644
> --- a/README
> +++ b/README
> @@ -27,7 +27,7 @@ Or to install into a private user specific location
> The following mandatory dependencies are required in order to
> build SPICE
> 
> -Spice protocol >= 0.9.0
> +Spice protocol >= 0.12.13

What is the rationale for spice-protocol not being a submodule?


> Pixman >= 0.17.7
> OpenSSL
> libjpeg
> -- 
> 2.13.3
> 
> ___
> 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] [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code

[Christophe de Dinechin]

> On 27 Jul 2017, at 15:07, Frediano Ziglio  wrote:
> 
> On 27 Jul 2017, at 12:39, Christophe Fergeau  > wrote:
> 
> On Thu, Jul 27, 2017 at 11:54:08AM +0200, Victor Toso wrote:
> On Mon, Jul 24, 2017 at 10:47:34AM -0400, Frediano Ziglio wrote:
> Not really familiar with GitLab merge requests but on GitHub they
> remain open till closed so this would help with old ones.
> The big change on moving to full PR is the way of commenting patches.
> Unless PR are just used for tracking and are replicated to ML but
> maybe is hard to keep them consistent. I think is possible to configure
> PRs to send changes to ML. This would make the history persistent on
> the ML.
> 
> Could we try for a period and see how does it go?
> 
> +1, but how should we approach that? I think we need to move from
> freedesktop to either gitlab or github first otherwise we can get
> confused on what's going on.
> 
> 
> Just to be sure, you are both suggesting switching to pull requests, and
> doing the reviews in gitlab web UI?
> 
> Not me. Reviewing by mail is fine with me.
> 
> Actually, Im concerned that if we switch to PR/MR, then some comments
> will end up being made only there, which is why I asked if there was a
> way to forward these comments to the mailing list. I believe this
> is possible from the group administration (its certainly possible
> for individual accounts on gitlab).
> 
> 
> The initial problem is that some reviews are not done in a timely
> manner. Being able to easily get a list of pending reviews was brought
> forward as a potential solution to this problem, and apparently, you
> both think that switching from email based reviews to a web based review
> system would help in getting more reviews faster? (iow, it would make
> you more efficient at reviewing code, and you vastly prefer that over
> email).
> 
> No, that’s not correct (at least for me). The review itself can happen over 
> mail,
> what I find inefficient is:
> 
> a) to get the list of things to review, and
> b) to get a working version of the code after patching
> 
> For a), email is good to notify you of recent reviews posted. But searching
> through e-mail for unreviewed stuff is not easy. Do you have a good trick for 
> that?
> 
> For b), Im not talking about git am. You may not realize that just
> figuring out which of our 17 repositories (not including personal
> ones) some particular patch applies to is not always obvious.
> 
> Im pretty sure this is not so much of a problem when you have worked
> longer on the project, so I am bringing that up precisely because
> Im still fresh enough to remember this being an issue.
> 
> 
> 
> I'm not necessarily opposed to trying things out, I'm just trying to get
> a clear view of what we are expecting to get out of the change.
> 
> First things first, if we want to try MR/PR, we should switch to gitlab
> as the primary. I understand there was a desire to do that also because
> freedesktop user creation was slow.
> 
> Would this be a valid first step?
> 
> 
> Christophe
> There's already https://gitlab.com/spice/spice 
> 

Yes, but it’s a clone of freedesktop instead of the other way round. So as I 
pointed out in an earlier email, if we enable merge requests there, we may end 
up with merge commits, and then a push from freeedesktop will run into trouble.

So if we want to try MR on gitlab.com, then we need gitlab to be primary and 
freedesktop to be the mirror, I believe.


Christophe



> 
> Frediano
> 

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

Re: [Spice-devel] [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code

[Christophe de Dinechin]

> On 27 Jul 2017, at 12:53, Daniel P. Berrange  wrote:
> 
> On Thu, Jul 27, 2017 at 12:39:32PM +0200, Christophe Fergeau wrote:
>> On Thu, Jul 27, 2017 at 11:54:08AM +0200, Victor Toso wrote:
>>> On Mon, Jul 24, 2017 at 10:47:34AM -0400, Frediano Ziglio wrote:
 Not really familiar with GitLab merge requests but on GitHub they
 remain open till closed so this would help with old ones.
 The big change on moving to full PR is the way of commenting patches.
 Unless PR are just used for tracking and are replicated to ML but
 maybe is hard to keep them consistent. I think is possible to configure
 PRs to send changes to ML. This would make the history persistent on
 the ML.
 
 Could we try for a period and see how does it go?
>>> 
>>> +1, but how should we approach that? I think we need to move from
>>> freedesktop to either gitlab or github first otherwise we can get
>>> confused on what's going on.
>>> 
>> 
>> Just to be sure, you are both suggesting switching to pull requests, and
>> doing the reviews in gitlab web UI?
>> 
>> The initial problem is that some reviews are not done in a timely
>> manner. Being able to easily get a list of pending reviews was brought
>> forward as a potential solution to this problem, and apparently, you
>> both think that switching from email based reviews to a web based review
>> system would help in getting more reviews faster? (iow, it would make
>> you more efficient at reviewing code, and you vastly prefer that over
>> email).
>> 
>> I'm not necessarily opposed to trying things out, I'm just trying to get
>> a clear view of what we are expecting to get out of the change.
> 
> IME, if you're not getting fast enough reviews on patches, the problem
> isn't usually the tools, it is the lack of reviewer bandwidth. On OpenStack
> we used Gerrit for reviewers, had tonnes of pretty graphs, metrics, reports
> on what reviews were stalled, how long reviews were waited for, etc, etc.
> It didn't help getting reviews done in a timely manner. You still had to
> go and manually "ping" people to get attention on your reviews they had
> not looked at or forgotten about.

+1 on your analysis, but I the problem I heard about was not that we don’t go 
fast enough,
but rather that some patches get dropped.

> 
> Added to that the web UI was so inefficient to deal with (particularly for
> patch series), that people ended up writing command line tools to do code
> review in a "email like" user interface and then posting the results back
> to gerrit.

This is why I’m really advocating baby steps. Stick to mail for now, just have 
one
shared place where we agree to post “large” things under review. I suggested
pushing branches with some naming conventions because we are on freedesktop
which has no merge request. If we switch to gitlab or github, a merge request or
pull request would be perfectly fine.

Small one-liners are usually reviewed instantly, so as Christophe pointed out, 
it’s
probably not worth it for small things.

> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com   -o-
> https://www.flickr.com/photos/dberrange 
>  :|
> |: https://libvirt.org  -o-
> https://fstop138.berrange.com  :|
> |: https://entangle-photo.org -o-
> https://www.instagram.com/dberrange  :|
> ___
> 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] Proposal: review branches (was Re: [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code)

[Christophe de Dinechin]

> On 27 Jul 2017, at 14:28, Marc-André Lureau  
> wrote:
> 
> Hi
> 
> - Original Message -
>> 
>>> On 26 Jul 2017, at 11:23, Marc-André Lureau 
>>> wrote:
>>> 
>>> Hi
>>> 
>>> - Original Message -
 Now, any objection to
 
 1. Recommending that we use git URLs in patches?
>>> 
>>> If that may help, but as Christophe said, this may be overkill for small
>>> series. Let's not make it a rule.
>>> 
 2. Having a shared location for branches under review?
>>> 
>>> This is really contrary to the distributed nature of git.
>> 
>> If that was true, why would the inventor of git, Linus Torvalds, use a public
>> shared place like kernel.org?
>> 
>> Git gives you the freedom to have multiple repos and sync them easily. It
>> does not place a restriction that you can’t have a shared one for a team.
>> 
>>> 
>>> Add a remote remote repo if you are interested by tracking someone else
>>> work, it works just as well.
>> 
>> No, it does not. It means you need to git fetch multiple places. It’s
>> complicated enough that there are 17 repositories in the spice project. For
>> one of them I have 12 remotes already. That does not scale well.
> 
> git remote add/update, it scales fine..

Here is a recent example. For the work on the streaming agent, I recently
ran into a compilation error because spice-prootocol was not the “right one”
for the code being reviewed, which was IIRC in the spice server. It turns out
that the only one I found that was “right” was some personal branch that
Frediano has somewhere.

How does git remote add/update help solve that, when the problem was
precisely to find the remote and branch?



> 
>>> 
>>> Imho, we could benefit using a system tracking patch series state from the
>>> mailing list, such as patchew. But it would probably need some work to fit
>>> Spice needs.
>> 
>> We would benefit from that, yes. But that’s another issue entirely.
> 
> If the issue is about tracking patch series state, then it's not not entirely 
> different.

It looks more like a way to manage incoming emails. Useful too, and related on 
the CI aspect.


> 
> Thanks
> ___
> 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] [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code

[Christophe de Dinechin]

> On 27 Jul 2017, at 12:39, Christophe Fergeau  wrote:
> 
> On Thu, Jul 27, 2017 at 11:54:08AM +0200, Victor Toso wrote:
>> On Mon, Jul 24, 2017 at 10:47:34AM -0400, Frediano Ziglio wrote:
>>> Not really familiar with GitLab merge requests but on GitHub they
>>> remain open till closed so this would help with old ones.
>>> The big change on moving to full PR is the way of commenting patches.
>>> Unless PR are just used for tracking and are replicated to ML but
>>> maybe is hard to keep them consistent. I think is possible to configure
>>> PRs to send changes to ML. This would make the history persistent on
>>> the ML.
>>> 
>>> Could we try for a period and see how does it go?
>> 
>> +1, but how should we approach that? I think we need to move from
>> freedesktop to either gitlab or github first otherwise we can get
>> confused on what's going on.
>> 
> 
> Just to be sure, you are both suggesting switching to pull requests, and
> doing the reviews in gitlab web UI?

Not me. Reviewing by mail is fine with me.

Actually, Im concerned that if we switch to PR/MR, then some comments
will end up being made only there, which is why I asked if there was a
way to forward these comments to the mailing list. I believe this
is possible from the group administration (its certainly possible
for individual accounts on gitlab).

> 
> The initial problem is that some reviews are not done in a timely
> manner. Being able to easily get a list of pending reviews was brought
> forward as a potential solution to this problem, and apparently, you
> both think that switching from email based reviews to a web based review
> system would help in getting more reviews faster? (iow, it would make
> you more efficient at reviewing code, and you vastly prefer that over
> email).

No, that’s not correct (at least for me). The review itself can happen over 
mail,
what I find inefficient is:

a) to get the list of things to review, and
b) to get a working version of the code after patching

For a), email is good to notify you of recent reviews posted. But searching
through e-mail for unreviewed stuff is not easy. Do you have a good trick for 
that?

For b), Im not talking about git am. You may not realize that just
figuring out which of our 17 repositories (not including personal
ones) some particular patch applies to is not always obvious.

Im pretty sure this is not so much of a problem when you have worked
longer on the project, so I am bringing that up precisely because
Im still fresh enough to remember this being an issue.


> 
> I'm not necessarily opposed to trying things out, I'm just trying to get
> a clear view of what we are expecting to get out of the change.

First things first, if we want to try MR/PR, we should switch to gitlab
as the primary. I understand there was a desire to do that also because
freedesktop user creation was slow.

Would this be a valid first step?

> 
> Christophe
> ___
> 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] [PATCH spice-server] README: Update required protocol version

[Christophe de Dinechin]

> On 27 Jul 2017, at 16:04, Christophe Fergeau <cferg...@redhat.com> wrote:
> 
> On Thu, Jul 27, 2017 at 03:29:11PM +0200, Christophe de Dinechin wrote:
>> 
>>> On 27 Jul 2017, at 15:25, Frediano Ziglio <fzig...@redhat.com> wrote:
>>> 
>>> Signed-off-by: Frediano Ziglio <fzig...@redhat.com>
>>> ---
>>> README | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/README b/README
>>> index 45fbe89c..0fd6f071 100644
>>> --- a/README
>>> +++ b/README
>>> @@ -27,7 +27,7 @@ Or to install into a private user specific location
>>> The following mandatory dependencies are required in order to
>>> build SPICE
>>> 
>>> -Spice protocol >= 0.9.0
>>> +Spice protocol >= 0.12.13
>> 
>> What is the rationale for spice-protocol not being a submodule?
> 
> It's used by multiple modules (spice-server, spice-gtk, the agent, the
> QX driver, ..) and has a stable API.

And how does any of that not make it not a submodule?

- Used by multiple modules: yes, that’s precisely what submodules are for 
(that’s also the case for spice-common).
- Has a stable API: yes, but when we need to change it, it would be nice to 
have that the change recorded in git history of the modules using it.

For example, a lot of the streaming work requires a branched-off spice-protocol.

I was also wondering about protocol updates being easier to do in a consistent 
way if spice-protocol was “above” spice-serverr and spice-gtk. Which could be 
solved by having a submodule structure like:

spice
spice-protocol
spice-common
spice-server
spice-gtk

instead of the current:

(nothing)
spice-protocol
spice (not called spice-server)
spice-common
spice-gtk
spice-common

Christophe

> 
> Christophe
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org <mailto:Spice-devel@lists.freedesktop.org>
> https://lists.freedesktop.org/mailman/listinfo/spice-devel 
> <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

[Spice-devel] Survey of repository preferences

[Christophe de Dinechin]

Following the recent discussions about pull requests, merge requests and 
marsupilamis, I’ve put together a small Google form at 
https://goo.gl/forms/bE3UON0zH30sGrg13 to capture the team preferences. I’ve 
used multiple-choice answers on purpose, so that we end up with actionable 
numbers. For a more detailed discussion, there’s mail ;-D


Regards
Christophe


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

Re: [Spice-devel] Survey of repository preferences

[Christophe de Dinechin]

> On 27 Jul 2017, at 16:40, Frediano Ziglio  wrote:
> 
>> 
>> Following the recent discussions about pull requests, merge requests and
>> marsupilamis, I’ve put together a small Google form at
>> https://goo.gl/forms/bE3UON0zH30sGrg13 to capture the team preferences. I’ve
>> used multiple-choice answers on purpose, so that we end up with actionable
>> numbers. For a more detailed discussion, there’s mail ;-D
>> 
>> 
>> Regards
>> Christophe
>> 
> 
> Why there are no questions about how do we want to review
> beside PRs?

Baby steps ;-) I was focusing on repo changes for the moment. But it may be the 
right time to create another form.


Christophe

> 
> Frediano

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

Re: [Spice-devel] Survey of repository preferences

[Christophe de Dinechin]

> On 27 Jul 2017, at 16:49, Marc-André Lureau  
> wrote:
> 
> Hi
> 
> - Original Message -
>> Following the recent discussions about pull requests, merge requests and
>> marsupilamis, I’ve put together a small Google form at
>> https://goo.gl/forms/bE3UON0zH30sGrg13 to capture the team preferences. I’ve
>> used multiple-choice answers on purpose, so that we end up with actionable
>> numbers. For a more detailed discussion, there’s mail ;-D
>> 
> 
> You put a lot of unrelated questions, and no rationale behind it.

The rationale was discussed here moments ago.


> There are a lot to say about the problems created by your various proposals, 
> and no place to do it in the form.

I wrote in the intro email that this was on purpose. You want to discuss the 
problems created by the proposals, go ahead.


> I think we should rather find a consensus on the mailing list rather than 
> avoiding the discussion.

“Avoiding the discussion" sounds like a cheap and unjustified shot. Please 
discuss.

> 
> Thanks

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

Re: [Spice-devel] [PATCH spice-server] README: Update required protocol version

[Christophe de Dinechin]

> On 27 Jul 2017, at 17:00, Victor Toso <victort...@redhat.com> wrote:
> 
> Hi,
> 
> On Thu, Jul 27, 2017 at 04:28:59PM +0200, Christophe de Dinechin wrote:
>> 
>>> On 27 Jul 2017, at 16:04, Christophe Fergeau <cferg...@redhat.com> wrote:
>>> 
>>> On Thu, Jul 27, 2017 at 03:29:11PM +0200, Christophe de Dinechin wrote:
>>>> 
>>>>> On 27 Jul 2017, at 15:25, Frediano Ziglio <fzig...@redhat.com> wrote:
>>>>> 
>>>>> Signed-off-by: Frediano Ziglio <fzig...@redhat.com>
>>>>> ---
>>>>> README | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>> 
>>>>> diff --git a/README b/README
>>>>> index 45fbe89c..0fd6f071 100644
>>>>> --- a/README
>>>>> +++ b/README
>>>>> @@ -27,7 +27,7 @@ Or to install into a private user specific location
>>>>> The following mandatory dependencies are required in order to
>>>>> build SPICE
>>>>> 
>>>>> -Spice protocol >= 0.9.0
>>>>> +Spice protocol >= 0.12.13
>>>> 
>>>> What is the rationale for spice-protocol not being a submodule?
>>> 
>>> It's used by multiple modules (spice-server, spice-gtk, the agent,
>>> the QX driver, ..) and has a stable API.
>> 
>> And how does any of that not make it not a submodule?
>> 
>> - Used by multiple modules: yes, that’s precisely what submodules are
>>  for (that’s also the case for spice-common).
>> - Has a stable API: yes, but when we need to change it, it would be
>>  nice to have that the change recorded in git history of the modules
>>  using it.
>> 
>> For example, a lot of the streaming work requires a branched-off
>> spice-protocol.
>> 
>> I was also wondering about protocol updates being easier to do in a
>> consistent way if spice-protocol was “above” spice-serverr and
>> spice-gtk. Which could be solved by having a submodule structure like:
>> 
>>  spice
>>  spice-protocol
>>  spice-common
>>  spice-server
>>  spice-gtk
>> 
>> instead of the current:
>> 
>>  (nothing)
>>  spice-protocol
>>  spice (not called spice-server)
>>  spice-common
>>  spice-gtk
>>  spice-common
>> 
>> Christophe
> 
> Another discussion about how things should be done?

Not how things should be done, more “why are they done like this”. Trying to 
understand if
it’s just “design by history and random evolution” or if there is an actual 
rationale behind it.

> 
> I don't see what you want to achieve here. Renaming? spice-protocol as
> submodule? Why do you think this is important?

As I wrote above, if only because spice-protocol is currently a branch for the 
streaming work.

If I want to share a series of patch that impact multiple components, say (at 
random) my
flight recorder work, I don’t see a good / consistent way to do it today.

- Should I make ‘recorder’ an independent module like spice-protocol? But if 
so, how do I sync it with the code using it?
- Should I make it a submodule like spice-common? But then, isn’t it annoying 
to have that in half a dozen projects?

What do you think is the correct way?


Christophe

> 
>> 
>>> 
>>> Christophe
>>> ___
>>> Spice-devel mailing list
>>> Spice-devel@lists.freedesktop.org <mailto:Spice-devel@lists.freedesktop.org>
>>> https://lists.freedesktop.org/mailman/listinfo/spice-devel 
>>> <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
> 
> ___
> 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

[Spice-devel] Form regarding preferences for repo layout

[christophe . de . dinechin]

I've invited you to fill out the following form:
Reorganizing Spice repositories

To fill it out, visit:
https://docs.google.com/forms/d/e/1FAIpQLSelX_VxzoO64ruoBN1rAbkVQWcyLrJNvBS_vVF_fK09p43x3w/viewform?c=0w=1includes_info_params=trueusp=mail_form_link

Following the recent discussion on repositories, merge requests, etc, I  
think it would be nice to have a kind of survey on the preferences of  
various team members. The form is a multiple-choice form on purpose, so  
that we can take action based on the results. For further discussion,  
please feel free to use mail.


Google Forms: Create and analyze surveys.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Survey of repository preferences

[Christophe de Dinechin]

> On 27 Jul 2017, at 17:07, Marc-André Lureau  
> wrote:
> 
> Hi
> 
> - Original Message -
>>> I think we should rather find a consensus on the mailing list rather than
>>> avoiding the discussion.
>> 
>> “Avoiding the discussion" sounds like a cheap and unjustified shot. Please
>> discuss.
> 
> You are the one making proposal, you should come up with rationale. but ok

As I wrote, the rationale was discussed on this list between yesterday and 
today. I’ll repeat it here. Now, you were the one saying there were “problems”. 
I cannot guess the problems you have with my proposals if you don’t discuss 
them.

> 
>> 
>>> 
> 
> - Use gitlab/github as primary, make freedesktop a mirror *?
> 
> What benefit does that bring?

It is to get these additional features, that AFAIK freedesktop lacks:

1. Continuous integration
2. Merge requests or pull requests
3. Being actually open (reported by Christophe Fergeau). For example, it took 
me 6 months to get a working freedesktop account

> The canonical source is hosted on freedesktop for ages.

That does not need to change.

> The role of this is a stable & controlled git repo to pull/push code to.

Why do I get a sense that “controlled” is the keyword here? ;-)

> Moving it to a different location doesn't change that. Using github/gitlab as 
> mirrors allows to have all the benefits of those hosting services.

To the best of my knowledge, that statement is incorrect

Specifically, we cannot enable merge requests on a mirror easily, because that 
means if we accept the merge request on gitlab, then gitlab is ahead of 
freedesktop, and when we push from freedesktop, that push is either rejected, 
or if we use push -f, we lose the merge.

Similarly, continuous integration on development branches, i.e. before we 
actually merge them, is not possible with freedesktop, even less so if your 
sense of “control” means you feel it’s OK to delete a review branch I push 
there without asking me first. All that is a bit moot anyway, because Google 
“freedesktop continuous integration” gives me nothing on the first page. 

> So why?

Because I think that continuous integration and a list of pending merge 
requests are more important than preserving the “we have been doing that for 
ages” comfort zone.

> 
> - Rename spice as spice-server

- To unambiguously leave ‘spice’ as the name for a top-level repository.
- So that mail-processing script does not have to do extra ad-hockery to map 
[PATCH spice-server] to a repo not named spice-server

Apparently, I’m not the first one to have the (obvious) idea, cf 
https://cgit.freedesktop.org/spice/spice-server (yet another confusing thing 
for newbies ;-)

> - Rename other repositories so that all children repos begin with 'spice-' *
> 
> I wasn't aware of that discussion, but changing a project name brings a 
> number of issues for distributions and people watching releases etc. Renaming 
> stuff is always problematic, what is the benefit?

Mostly to disambiguate between modules we really own (most of them) and modules 
that seem to be external dependencies for the spice project. For example, are 
libcacard or usbredir used by other projects?

Is spice/qemu an external dependency, is it there fore convenience? Or is that 
just obsolete? What about spice/spicec, spice/vdesktop, … I have a feeling 
there are a few stale repositories there.

The logical structure found in https://cgit.freedesktop.org/spice is nice. It’s 
not clearly visible e.g. on spice-space.org. And AFAIK, it’s not visible to git.

> 
> - Create top-level repository with all others repositories as submodules (if 
> we use 'spice-server', that one would be called 'spice') *
> 
> Isn't this already the case? https://cgit.freedesktop.org/spice/

If that’s the case, it’s cool. But it looks like a group of repositories in 
freedesktop, more than a repository with submodules. What is the git clone 
command to clone that top-level repo?

Having a top-level repository makes work on branches that impact multiple 
components easier. Case in point today: streaming impacts server, protocol, 
agent, client, etc. So being able to easily switch to the “stream” branch and 
update protocol, agent, client and server in one command (ok, two, git checkout 
following by git submodule update) is useful.

> 
> How you really mean "git submodules".. Eh, what's the point? Sounds very 
> wrong and useless to me, it will be constantly outdated.. Write a script 
> instead?

What I really mean is something like this: https://gitlab.com/c3d/spice. I did 
that quickly, but ultimately, I’d like to have READMEs and global build 
scripts, to put spice-space repositories under “docs”, that kind of things.


> 
> - Make spice-protocol a submodule of modules that use it 
> 
> We have been there before with spice-gtk/spice-common, and it was reverted.

But spice-common is still a submodule, so I don’t understand why you bring it 
up. Unless you are talking about removal 

Re: [Spice-devel] [PATCH spice-server] README: Update required protocol version

[Christophe de Dinechin]

> On 27 Jul 2017, at 17:06, Christophe Fergeau <cferg...@redhat.com> wrote:
> 
> On Thu, Jul 27, 2017 at 04:28:59PM +0200, Christophe de Dinechin wrote:
>> 
>>> On 27 Jul 2017, at 16:04, Christophe Fergeau <cferg...@redhat.com> wrote:
>>> 
>>> On Thu, Jul 27, 2017 at 03:29:11PM +0200, Christophe de Dinechin wrote:
>>>> 
>>>>> On 27 Jul 2017, at 15:25, Frediano Ziglio <fzig...@redhat.com> wrote:
>>>>> 
>>>>> Signed-off-by: Frediano Ziglio <fzig...@redhat.com>
>>>>> ---
>>>>> README | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>> 
>>>>> diff --git a/README b/README
>>>>> index 45fbe89c..0fd6f071 100644
>>>>> --- a/README
>>>>> +++ b/README
>>>>> @@ -27,7 +27,7 @@ Or to install into a private user specific location
>>>>> The following mandatory dependencies are required in order to
>>>>> build SPICE
>>>>> 
>>>>> -Spice protocol >= 0.9.0
>>>>> +Spice protocol >= 0.12.13
>>>> 
>>>> What is the rationale for spice-protocol not being a submodule?
>>> 
>>> It's used by multiple modules (spice-server, spice-gtk, the agent, the
>>> QX driver, ..) and has a stable API.
>> 
>> And how does any of that not make it not a submodule?
>> 
>> - Used by multiple modules: yes, that’s precisely what submodules are
>> for (that’s also the case for spice-common).
> 
> That's also the use case for installed stuff that you look up through
> pkg-config. glib2 is used by multiple modules, but I see noone
> suggesting adding it a submodule.

Of course not, it’s an entirely different project, it’s not the core protocol 
used by all components!

> 
>> - Has a stable API: yes, but when we need to change it, it would be
>> nice to have that the change recorded in git history of the modules
>> using it.
> 
> We have a vague recording of that when you change the minimal required
> version of spice-protocol in configure.ac.

I love the “vague recording” ;-)

> 
>> 
>> For example, a lot of the streaming work requires a branched-off 
>> spice-protocol.
>> 
>> I was also wondering about protocol updates being easier to do in a
>> consistent way if spice-protocol was “above” spice-server and
>> spice-gtk. Which could be solved by having a submodule structure like:
>> 
>>  spice
>>  spice-protocol
>>  spice-common
>>  spice-server
>>  spice-gtk
> 
> I'm not sure generating spice-gtk and spice-server tarballs from such a layout
> would be easy (?)

Are you saying that it’s logical to include spice-common in the tarball, but 
not spice-protocol?

> 
> For what it's worth, I find submodules quite cumbersome to work with,
> they get in the way more often than not when you start making changes in
> one, when you start applying patches inside a submodule, rebasing, …

So you think that if / when Frediano rebases the stream branch in 
git://people.freedesktop.org/~fziglio/spice-protocol, I won’t have these 
problems? Of course I will. The only difference is that *git will not tell me*.

>> 
>> instead of the current:
>> 
>>  (nothing)
> 
> Which is bad because?
> 
> I believe what you are trying to improve is the case when an invasive
> change is being made in both spice-gtk and spice-server, with required
> changes in spice-protocol?

Yes, which is precisely what is happening with streaming, 
https://github.com/SPICE/spice-protocol/compare/master...c3d:stream.
Where the “canonical” source is, as far as I know, 
git://people.freedesktop.org/~fziglio/spice-protocol.

> If yes, I don't think anything would force people to have the
> over-arching spice/ module up to date, they could just work only in
> spice/spice-gtk, or in spice/spice-server,

And working in these submodules without updating the top-level is perfectly 
find, as long as you work in only one.


> and you'd have the same issue
> as you currently are having, no?

I don’t think I would, because my problem is with branches I’m currently 
working on where multiple components are impacted at once:

- The streaming work.
- The flight recorder work, which led me to these questions (should ‘recorder’ 
follow the spice-common or spice-protocol model?)
- My investigation on sending feedback to the server from bogged down clients


> 
> Christophe
> ___
> 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] [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code

[Christophe de Dinechin]

> On 27 Jul 2017, at 15:53, Christophe Fergeau <cferg...@redhat.com> wrote:
> 
> On Thu, Jul 27, 2017 at 03:00:27PM +0200, Christophe de Dinechin wrote:
>> No, that’s not correct (at least for me). The review itself can happen over 
>> mail,
>> what I find inefficient is:
>> 
>> a) to get the list of things to review, and
>> b) to get a working version of the code after patching
>> 
> 
> [snip]
> 
>> For b), Im not talking about git am. You may not realize that just
>> figuring out which of our 17 repositories (not including personal
>> ones) some particular patch applies to is not always obvious.
> 
> Patches sent to this mailing list should apply to git master, the name
> of the project this applies too is supposed to be present in the email
> subject. Occasionally, a series won't apply on master because a
> conflicting patch was pushed, or a series will have a dependency on
> another one. When a series is not meant to apply on git master, this
> should be made very clear in the cover letter.
> 
> Another thing which can get tricky is when a spice patch depends on a
> spice-common patch, which requires a spice-protocol change :)
> 
> Is this what you were talking about?

Yes.

> 
> Christophe
> ___
> 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] Proposal: review branches (was Re: [vdagent-win PATCH v6 2/5] Initial rewrite of image conversion code)

[Christophe de Dinechin]

> On 27 Jul 2017, at 17:08, Frediano Ziglio  wrote:
> 
> Try to sum up the initial problem was patches/series tracking
> 
> So far there are 3 proposal
> 1) PR/MR (GitLab/GitHub style)
> 2) patchew
> 3a) shared git repository
> 3b) links to external git repositories
> 
> 1) PR surely can trace the status of series and is ready to
>   use with small initial setup. Not clear if we would like
>   to do reviews with it;

Not many answers to my survey yet, but so far a consensus that
patches should be sent to the mailing list, which I interpret as
an indication that people are comfortable with mail-based reviews.


> 2) similar to patchwork with additional feature but missing
>   the state tracking part. Maybe would be not hard to add;

To me, addresses a different issue, so I would propose both 1 and 2.
Specifically, 1 addresses the server side (managing CI items, list of branches
under review, build status, etc), whereas 2 addresses the mail side
(turning patches into “CI items”).


> 3a) Many disagree as not really git ideal and about
>external contributions;
> 3b) Does this improve knowing the state of series? Maybe
>for internal developers only.

I think that 1 implies 3, doesn’t it?

> 
> 3a/3b seems quite manual job to do and not much solving
> the state tracking (although solve other issues), maybe
> some ideas could improve the current procedure.
> 
> Maybe would be worth speaking with patchew author if
> is easy doable and agree with the change.
> 
> IMHO the "closest" (more suitable and easy to implement)
> is 1.

Agreed. But I think 2 would be a valuable addition, notably as
an efficient way to deal with smaller patches.


Thanks,
Christophe
> 
> Frediano
> ___
> 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] [PATCH spice-server] README: Update required protocol version

[Christophe de Dinechin]

> On 27 Jul 2017, at 17:35, Frediano Ziglio <fzig...@redhat.com> wrote:
> 
>> 
>> 
>>> On 27 Jul 2017, at 17:00, Victor Toso <victort...@redhat.com> wrote:
>>> 
>>> Hi,
>>> 
>>> On Thu, Jul 27, 2017 at 04:28:59PM +0200, Christophe de Dinechin wrote:
>>>> 
>>>>> On 27 Jul 2017, at 16:04, Christophe Fergeau <cferg...@redhat.com> wrote:
>>>>> 
>>>>> On Thu, Jul 27, 2017 at 03:29:11PM +0200, Christophe de Dinechin wrote:
>>>>>> 
>>>>>>> On 27 Jul 2017, at 15:25, Frediano Ziglio <fzig...@redhat.com> wrote:
>>>>>>> 
>>>>>>> Signed-off-by: Frediano Ziglio <fzig...@redhat.com>
>>>>>>> ---
>>>>>>> README | 2 +-
>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>> 
>>>>>>> diff --git a/README b/README
>>>>>>> index 45fbe89c..0fd6f071 100644
>>>>>>> --- a/README
>>>>>>> +++ b/README
>>>>>>> @@ -27,7 +27,7 @@ Or to install into a private user specific location
>>>>>>> The following mandatory dependencies are required in order to
>>>>>>> build SPICE
>>>>>>> 
>>>>>>> -Spice protocol >= 0.9.0
>>>>>>> +Spice protocol >= 0.12.13
>>>>>> 
>>>>>> What is the rationale for spice-protocol not being a submodule?
>>>>> 
>>>>> It's used by multiple modules (spice-server, spice-gtk, the agent,
>>>>> the QX driver, ..) and has a stable API.
>>>> 
>>>> And how does any of that not make it not a submodule?
>>>> 
>>>> - Used by multiple modules: yes, that’s precisely what submodules are
>>>> for (that’s also the case for spice-common).
>>>> - Has a stable API: yes, but when we need to change it, it would be
>>>> nice to have that the change recorded in git history of the modules
>>>> using it.
>>>> 
>>>> For example, a lot of the streaming work requires a branched-off
>>>> spice-protocol.
>>>> 
>>>> I was also wondering about protocol updates being easier to do in a
>>>> consistent way if spice-protocol was “above” spice-serverr and
>>>> spice-gtk. Which could be solved by having a submodule structure like:
>>>> 
>>>>spice
>>>>spice-protocol
>>>>spice-common
>>>>spice-server
>>>>spice-gtk
>>>> 
>>>> instead of the current:
>>>> 
>>>>(nothing)
>>>>spice-protocol
>>>>spice (not called spice-server)
>>>>spice-common
>>>>spice-gtk
>>>>spice-common
>>>> 
>>>> Christophe
>>> 
>>> Another discussion about how things should be done?
>> 
>> Not how things should be done, more “why are they done like this”. Trying to
>> understand if
>> it’s just “design by history and random evolution” or if there is an actual
>> rationale behind it.
>> 
>>> 
>>> I don't see what you want to achieve here. Renaming? spice-protocol as
>>> submodule? Why do you think this is important?
>> 
>> As I wrote above, if only because spice-protocol is currently a branch for
>> the streaming work.
>> 
>> If I want to share a series of patch that impact multiple components, say (at
>> random) my
>> flight recorder work, I don’t see a good / consistent way to do it today.
>> 
>> - Should I make ‘recorder’ an independent module like spice-protocol? But if
>> so, how do I sync it with the code using it?
>> - Should I make it a submodule like spice-common? But then, isn’t it annoying
>> to have that in half a dozen projects?
>> 
>> What do you think is the correct way?
>> 
>> 
>> Christophe
>> 
> 
> So... you open a forum after we are discussing PRs and so on
> with questions about repository renames, you reply to a mail
> that update a dependency version in a README file and at the
> end you ask why you can't do with your `recorder`.
> Maybe it's just me but I'm a bit confused :-)

Believe me, I’m more confused than you are.

I should have made it clear since the start that all my questions stem from
the trouble I have finding the right way to do t