[Spice-devel] [spice-common][PATCH 1/2] quic: Fix UNINIT caught by coverity
In case of the model evolution mode has a obsolete or non-valid value, just return, avoiding then the usage of non initalized variables. --- common/quic.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/common/quic.c b/common/quic.c index 4584336..90ea47b 100644 --- a/common/quic.c +++ b/common/quic.c @@ -911,9 +911,12 @@ static void find_model_params(Encoder *encoder, unsigned int bstart, bend = 0; /* bucket start and end, range : 0 to levels-1*/ unsigned int repcntr;/* helper */ +/* The only valid values are 1, 3 and 5. + 0, 2 and 4 are obsolete and the rest of the + values are considered out of the range. */ +spice_static_assert (evol == 1 || evol == 3 || evol == 5); spice_assert(bpc = 8 bpc 0); - *ncounters = 8; *levels = 0x1 bpc; @@ -939,14 +942,9 @@ static void find_model_params(Encoder *encoder, *repnext = 1; *mulsize = 4; break; -case 0: /* obsolete */ -case 2: /* obsolete */ -case 4: /* obsolete */ -encoder-usr-error(encoder-usr, findmodelparams(): evol value obsolete!!!\n); -break; default: encoder-usr-error(encoder-usr, findmodelparams(): evol out of range!!!\n); -break; +return; } *nbuckets = 0; -- 1.9.3 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [spice-gtk][PATCH] Prefer using g_malloc0()/g_free()
As we already depend on GLib, let's use g_{malloc,new}0() instead of the standard malloc() or the spice_{malloc,new}*() and g_free() instead of the standard free() when possible. Memory allocated by other libraries using malloc() should still be freed by free(). As a side effect of the changes, we are muting a few warnings caught by coverity. --- gtk/channel-cursor.c | 2 +- gtk/channel-display-mjpeg.c | 8 +++- gtk/channel-display.c | 8 gtk/channel-main.c| 12 ++-- gtk/channel-record.c | 2 +- gtk/channel-webdav.c | 4 ++-- gtk/controller/test.c | 4 ++-- gtk/decode-glz.c | 10 +- gtk/decode-jpeg.c | 2 +- gtk/decode-zlib.c | 2 +- gtk/spice-channel.c | 20 ++-- gtk/spice-client-gtk.override | 7 --- gtk/spice-session.c | 2 +- gtk/spice-widget.c| 2 +- gtk/usb-device-manager.c | 2 +- 15 files changed, 43 insertions(+), 44 deletions(-) diff --git a/gtk/channel-cursor.c b/gtk/channel-cursor.c index a7d7153..ae788dc 100644 --- a/gtk/channel-cursor.c +++ b/gtk/channel-cursor.c @@ -323,7 +323,7 @@ static display_cursor *set_cursor(SpiceChannel *channel, SpiceCursor *scursor) g_return_val_if_fail(scursor-data_size != 0, NULL); size = 4u * hdr-width * hdr-height; -cursor = spice_malloc(sizeof(*cursor) + size); +cursor = g_malloc0(sizeof(*cursor) + size); cursor-hdr = *hdr; cursor-default_cursor = FALSE; cursor-refcount = 1; diff --git a/gtk/channel-display-mjpeg.c b/gtk/channel-display-mjpeg.c index 2ad653e..95d5b33 100644 --- a/gtk/channel-display-mjpeg.c +++ b/gtk/channel-display-mjpeg.c @@ -73,11 +73,9 @@ void stream_mjpeg_data(display_stream *st) uint8_t *lines[4]; stream_get_dimensions(st, width, height); -dest = malloc(width * height * 4); +dest = g_malloc0(width * height * 4); -if (st-out_frame) { -free(st-out_frame); -} +g_free(st-out_frame); st-out_frame = dest; jpeg_read_header(st-mjpeg_cinfo, 1); @@ -153,6 +151,6 @@ G_GNUC_INTERNAL void stream_mjpeg_cleanup(display_stream *st) { jpeg_destroy_decompress(st-mjpeg_cinfo); -free(st-out_frame); +g_free(st-out_frame); st-out_frame = NULL; } diff --git a/gtk/channel-display.c b/gtk/channel-display.c index 6265334..6fa97aa 100644 --- a/gtk/channel-display.c +++ b/gtk/channel-display.c @@ -730,7 +730,7 @@ static void destroy_canvas(display_surface *surface) jpeg_decoder_destroy(surface-jpeg_decoder); if (surface-shmid == -1) { -free(surface-data); +g_free(surface-data); } #ifdef HAVE_SYS_SHM_H else { @@ -986,7 +986,7 @@ static void display_handle_stream_create(SpiceChannel *channel, SpiceMsgIn *in) memset(c-streams + n, 0, (c-nstreams - n) * sizeof(c-streams[0])); } g_return_if_fail(c-streams[op-id] == NULL); -c-streams[op-id] = spice_new0(display_stream, 1); +c-streams[op-id] = g_new0(display_stream, 1); st = c-streams[op-id]; st-msg_create = in; @@ -1486,7 +1486,7 @@ static void destroy_stream(SpiceChannel *channel, int id) g_queue_free(st-msgq); if (st-timeout != 0) g_source_remove(st-timeout); -free(st); +g_free(st); c-streams[id] = NULL; } @@ -1498,7 +1498,7 @@ static void clear_streams(SpiceChannel *channel) for (i = 0; i c-nstreams; i++) { destroy_stream(channel, i); } -free(c-streams); +g_free(c-streams); c-streams = NULL; c-nstreams = 0; } diff --git a/gtk/channel-main.c b/gtk/channel-main.c index 352499c..7a299a4 100644 --- a/gtk/channel-main.c +++ b/gtk/channel-main.c @@ -1050,7 +1050,7 @@ gboolean spice_main_send_monitor_config(SpiceMainChannel *channel) } size = sizeof(VDAgentMonitorsConfig) + sizeof(VDAgentMonConfig) * monitors; -mon = spice_malloc0(size); +mon = g_malloc0(size); mon-num_of_monitors = monitors; if (c-disable_display_position == FALSE || @@ -1081,7 +1081,7 @@ gboolean spice_main_send_monitor_config(SpiceMainChannel *channel) monitors_align(mon-monitors, mon-num_of_monitors); agent_msg_queue(channel, VD_AGENT_MONITORS_CONFIG, size, mon); -free(mon); +g_free(mon); spice_channel_wakeup(SPICE_CHANNEL(channel), FALSE); if (c-timer_id != 0) { @@ -1133,7 +1133,7 @@ static void agent_announce_caps(SpiceMainChannel *channel) return; size = sizeof(VDAgentAnnounceCapabilities) + VD_AGENT_CAPS_BYTES; -caps = spice_malloc0(size); +caps = g_malloc0(size); if (!c-agent_caps_received) caps-request = 1; VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_MOUSE_STATE); @@ -1144,7 +1144,7 @@ static void agent_announce_caps(SpiceMainChannel *channel) VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_CLIPBOARD_SELECTION); agent_msg_queue(channel, VD_AGENT_ANNOUNCE_CAPABILITIES,
Re: [Spice-devel] [spice-gtk][PATCH] Prefer using g_malloc0()/g_free()
ack - Original Message - As we already depend on GLib, let's use g_{malloc,new}0() instead of the standard malloc() or the spice_{malloc,new}*() and g_free() instead of the standard free() when possible. Memory allocated by other libraries using malloc() should still be freed by free(). As a side effect of the changes, we are muting a few warnings caught by coverity. --- gtk/channel-cursor.c | 2 +- gtk/channel-display-mjpeg.c | 8 +++- gtk/channel-display.c | 8 gtk/channel-main.c| 12 ++-- gtk/channel-record.c | 2 +- gtk/channel-webdav.c | 4 ++-- gtk/controller/test.c | 4 ++-- gtk/decode-glz.c | 10 +- gtk/decode-jpeg.c | 2 +- gtk/decode-zlib.c | 2 +- gtk/spice-channel.c | 20 ++-- gtk/spice-client-gtk.override | 7 --- gtk/spice-session.c | 2 +- gtk/spice-widget.c| 2 +- gtk/usb-device-manager.c | 2 +- 15 files changed, 43 insertions(+), 44 deletions(-) diff --git a/gtk/channel-cursor.c b/gtk/channel-cursor.c index a7d7153..ae788dc 100644 --- a/gtk/channel-cursor.c +++ b/gtk/channel-cursor.c @@ -323,7 +323,7 @@ static display_cursor *set_cursor(SpiceChannel *channel, SpiceCursor *scursor) g_return_val_if_fail(scursor-data_size != 0, NULL); size = 4u * hdr-width * hdr-height; -cursor = spice_malloc(sizeof(*cursor) + size); +cursor = g_malloc0(sizeof(*cursor) + size); cursor-hdr = *hdr; cursor-default_cursor = FALSE; cursor-refcount = 1; diff --git a/gtk/channel-display-mjpeg.c b/gtk/channel-display-mjpeg.c index 2ad653e..95d5b33 100644 --- a/gtk/channel-display-mjpeg.c +++ b/gtk/channel-display-mjpeg.c @@ -73,11 +73,9 @@ void stream_mjpeg_data(display_stream *st) uint8_t *lines[4]; stream_get_dimensions(st, width, height); -dest = malloc(width * height * 4); +dest = g_malloc0(width * height * 4); -if (st-out_frame) { -free(st-out_frame); -} +g_free(st-out_frame); st-out_frame = dest; jpeg_read_header(st-mjpeg_cinfo, 1); @@ -153,6 +151,6 @@ G_GNUC_INTERNAL void stream_mjpeg_cleanup(display_stream *st) { jpeg_destroy_decompress(st-mjpeg_cinfo); -free(st-out_frame); +g_free(st-out_frame); st-out_frame = NULL; } diff --git a/gtk/channel-display.c b/gtk/channel-display.c index 6265334..6fa97aa 100644 --- a/gtk/channel-display.c +++ b/gtk/channel-display.c @@ -730,7 +730,7 @@ static void destroy_canvas(display_surface *surface) jpeg_decoder_destroy(surface-jpeg_decoder); if (surface-shmid == -1) { -free(surface-data); +g_free(surface-data); } #ifdef HAVE_SYS_SHM_H else { @@ -986,7 +986,7 @@ static void display_handle_stream_create(SpiceChannel *channel, SpiceMsgIn *in) memset(c-streams + n, 0, (c-nstreams - n) * sizeof(c-streams[0])); } g_return_if_fail(c-streams[op-id] == NULL); -c-streams[op-id] = spice_new0(display_stream, 1); +c-streams[op-id] = g_new0(display_stream, 1); st = c-streams[op-id]; st-msg_create = in; @@ -1486,7 +1486,7 @@ static void destroy_stream(SpiceChannel *channel, int id) g_queue_free(st-msgq); if (st-timeout != 0) g_source_remove(st-timeout); -free(st); +g_free(st); c-streams[id] = NULL; } @@ -1498,7 +1498,7 @@ static void clear_streams(SpiceChannel *channel) for (i = 0; i c-nstreams; i++) { destroy_stream(channel, i); } -free(c-streams); +g_free(c-streams); c-streams = NULL; c-nstreams = 0; } diff --git a/gtk/channel-main.c b/gtk/channel-main.c index 352499c..7a299a4 100644 --- a/gtk/channel-main.c +++ b/gtk/channel-main.c @@ -1050,7 +1050,7 @@ gboolean spice_main_send_monitor_config(SpiceMainChannel *channel) } size = sizeof(VDAgentMonitorsConfig) + sizeof(VDAgentMonConfig) * monitors; -mon = spice_malloc0(size); +mon = g_malloc0(size); mon-num_of_monitors = monitors; if (c-disable_display_position == FALSE || @@ -1081,7 +1081,7 @@ gboolean spice_main_send_monitor_config(SpiceMainChannel *channel) monitors_align(mon-monitors, mon-num_of_monitors); agent_msg_queue(channel, VD_AGENT_MONITORS_CONFIG, size, mon); -free(mon); +g_free(mon); spice_channel_wakeup(SPICE_CHANNEL(channel), FALSE); if (c-timer_id != 0) { @@ -1133,7 +1133,7 @@ static void agent_announce_caps(SpiceMainChannel *channel) return; size = sizeof(VDAgentAnnounceCapabilities) + VD_AGENT_CAPS_BYTES; -caps = spice_malloc0(size); +caps = g_malloc0(size); if (!c-agent_caps_received) caps-request = 1; VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_MOUSE_STATE); @@ -1144,7 +1144,7 @@ static void
Re: [Spice-devel] [spice-common][PATCH 2/2] quic_family_tmpl: Fix FORWARD_NULL caught by coverity
ack - Original Message - Ensure the received bucket is non NULL --- common/quic_family_tmpl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/common/quic_family_tmpl.c b/common/quic_family_tmpl.c index 12ef62f..9a434e0 100644 --- a/common/quic_family_tmpl.c +++ b/common/quic_family_tmpl.c @@ -72,6 +72,8 @@ static void FNAME(update_model)(CommonState *state, s_bucket * const bucket, const BYTE curval) { spice_static_assert(BPC = 1); +spice_return_if_fail (bucket != NULL); + const unsigned int bpp = BPC; COUNTER * const pcounters = bucket-pcounters; unsigned int i; -- 1.9.3 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [spice-common][PATCH 1/2] quic: Fix UNINIT caught by coverity
ack - Original Message - In case of the model evolution mode has a obsolete or non-valid value, just return, avoiding then the usage of non initalized variables. --- common/quic.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/common/quic.c b/common/quic.c index 4584336..90ea47b 100644 --- a/common/quic.c +++ b/common/quic.c @@ -911,9 +911,12 @@ static void find_model_params(Encoder *encoder, unsigned int bstart, bend = 0; /* bucket start and end, range : 0 to levels-1*/ unsigned int repcntr;/* helper */ +/* The only valid values are 1, 3 and 5. + 0, 2 and 4 are obsolete and the rest of the + values are considered out of the range. */ +spice_static_assert (evol == 1 || evol == 3 || evol == 5); spice_assert(bpc = 8 bpc 0); - *ncounters = 8; *levels = 0x1 bpc; @@ -939,14 +942,9 @@ static void find_model_params(Encoder *encoder, *repnext = 1; *mulsize = 4; break; -case 0: /* obsolete */ -case 2: /* obsolete */ -case 4: /* obsolete */ -encoder-usr-error(encoder-usr, findmodelparams(): evol value obsolete!!!\n); -break; default: encoder-usr-error(encoder-usr, findmodelparams(): evol out of range!!!\n); -break; +return; } *nbuckets = 0; -- 1.9.3 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] Don't use _GET_PRIVATE all the time
Let's make use of the priv members in the structs, which are much much faster. Also, to keep the type-safety, the SPICE_IS_* macros were added in the public methods affected by this patch. Patch based on an old patch old patch from Alexander Larsson (al...@redhat.com). --- gtk/channel-cursor.c | 3 +- gtk/channel-smartcard.c | 29 +-- gtk/smartcard-manager.c | 4 +- gtk/spice-channel.c | 30 +++- gtk/spice-gstaudio.c | 11 +++-- gtk/spice-pulse.c| 39 --- gtk/spice-session.c | 122 --- gtk/spice-widget-cairo.c | 8 ++-- gtk/spice-widget-x11.c | 6 +-- gtk/spice-widget.c | 107 + 10 files changed, 199 insertions(+), 160 deletions(-) diff --git a/gtk/channel-cursor.c b/gtk/channel-cursor.c index ae788dc..e6514a2 100644 --- a/gtk/channel-cursor.c +++ b/gtk/channel-cursor.c @@ -88,7 +88,8 @@ static void spice_cursor_channel_init(SpiceCursorChannel *channel) static void spice_cursor_channel_finalize(GObject *obj) { -SpiceCursorChannelPrivate *c = SPICE_CURSOR_CHANNEL_GET_PRIVATE(obj); +SpiceCursorChannel *channel = SPICE_CURSOR_CHANNEL(obj); +SpiceCursorChannelPrivate *c = channel-priv; g_clear_pointer(c-cursors, cache_unref); diff --git a/gtk/channel-smartcard.c b/gtk/channel-smartcard.c index 7a7..d27360c 100644 --- a/gtk/channel-smartcard.c +++ b/gtk/channel-smartcard.c @@ -158,7 +158,8 @@ static void spice_smartcard_channel_constructed(GObject *object) static void spice_smartcard_channel_finalize(GObject *obj) { -SpiceSmartcardChannelPrivate *c = SPICE_SMARTCARD_CHANNEL_GET_PRIVATE(obj); +SpiceSmartcardChannel *channel = SPICE_SMARTCARD_CHANNEL(obj); +SpiceSmartcardChannelPrivate *c = channel-priv; if (c-pending_card_insertions != NULL) { g_hash_table_destroy(c-pending_card_insertions); @@ -187,7 +188,8 @@ static void spice_smartcard_channel_finalize(GObject *obj) static void spice_smartcard_channel_reset(SpiceChannel *channel, gboolean migrating) { -SpiceSmartcardChannelPrivate *c = SPICE_SMARTCARD_CHANNEL_GET_PRIVATE(channel); +SpiceSmartcardChannel *smartcard_channel = SPICE_SMARTCARD_CHANNEL(channel); +SpiceSmartcardChannelPrivate *c = smartcard_channel-priv; g_hash_table_remove_all(c-pending_card_insertions); g_hash_table_remove_all(c-pending_reader_removals); @@ -476,11 +478,11 @@ static void spice_smartcard_channel_up(SpiceChannel *channel) static void handle_smartcard_msg(SpiceChannel *channel, SpiceMsgIn *in) { #ifdef USE_SMARTCARD -SpiceSmartcardChannelPrivate *priv = SPICE_SMARTCARD_CHANNEL_GET_PRIVATE(channel); +SpiceSmartcardChannel *smartcard_channel = SPICE_SMARTCARD_CHANNEL(channel); +SpiceSmartcardChannelPrivate *priv = smartcard_channel-priv; SpiceMsgSmartcard *msg = spice_msg_in_parsed(in); VReader *reader; -priv = SPICE_SMARTCARD_CHANNEL_GET_PRIVATE(channel); CHANNEL_DEBUG(channel, handle msg %d, msg-type); switch (msg-type) { case VSC_Error: @@ -497,15 +499,14 @@ static void handle_smartcard_msg(SpiceChannel *channel, SpiceMsgIn *in) priv-pending_reader_additions); vreader_set_id(reader, msg-reader_id); -if (spice_channel_has_pending_card_insertion(SPICE_SMARTCARD_CHANNEL(channel), reader)) { -send_msg_atr(SPICE_SMARTCARD_CHANNEL(channel), reader); - spice_channel_drop_pending_card_insertion(SPICE_SMARTCARD_CHANNEL(channel), reader); +if (spice_channel_has_pending_card_insertion(smartcard_channel, reader)) { +send_msg_atr(smartcard_channel, reader); + spice_channel_drop_pending_card_insertion(smartcard_channel, reader); } -if (spice_channel_has_pending_reader_removal(SPICE_SMARTCARD_CHANNEL(channel), reader)) { -send_msg_generic(SPICE_SMARTCARD_CHANNEL(channel), - reader, VSC_CardRemove); - spice_channel_drop_pending_reader_removal(SPICE_SMARTCARD_CHANNEL(channel), reader); +if (spice_channel_has_pending_reader_removal(smartcard_channel, reader)) { +send_msg_generic(smartcard_channel, reader, VSC_CardRemove); + spice_channel_drop_pending_reader_removal(smartcard_channel, reader); } break; case VSC_APDU: @@ -518,7 +519,7 @@ static void handle_smartcard_msg(SpiceChannel *channel, SpiceMsgIn *in) g_warning(Unexpected message: %d, priv-in_flight_message-message_type); break; } - smartcard_message_complete_in_flight(SPICE_SMARTCARD_CHANNEL(channel)); +
[Spice-devel] video performance in rhel/centos 7 vs fedora 20
Hi All, We have been piloting deployments of VM using Fedora 20 host and guest and have been very happy with performance and stability in almost every respect, so a big thanks to all for this hard work. Things are looking great. Now we have been testing deployments of these same VMs (F20 guests) on rhel 7 (centos 7). We migrated one over and one of the issues seems to be a severe degradation of video performance vis-a-vis the F20 host. The setup is a C7 host, F20 guest and either C7 or F20 client, either local to the host or on the LAN. In this setup, the video plays fine for a few seconds, but eventually degrades to about 1fps with severe tearing of the video. Video does remain in sync with audio and there are no audio breakups. Any pointers on things to try? I'm willing to rebuild some host components (e.g. spice-server or qemu or whatever) or try some patches or configuration changes to address this to track it down. -- Thanks, David Mansfield Cobite, INC. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [vdagent-linux 2/2] Handle STRING selection type
This is to please vncviewer. https://bugzilla.redhat.com/show_bug.cgi?id=1117764 --- src/vdagent-x11-priv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/vdagent-x11-priv.h b/src/vdagent-x11-priv.h index 4a5729b..38f852e 100644 --- a/src/vdagent-x11-priv.h +++ b/src/vdagent-x11-priv.h @@ -64,8 +64,8 @@ struct monitor_size { }; static const struct clipboard_format_tmpl clipboard_format_templates[] = { -{ VD_AGENT_CLIPBOARD_UTF8_TEXT, { UTF8_STRING, - text/plain;charset=UTF-8, text/plain;charset=utf-8, NULL }, }, +{ VD_AGENT_CLIPBOARD_UTF8_TEXT, { UTF8_STRING, text/plain;charset=UTF-8, + text/plain;charset=utf-8, STRING, NULL }, }, { VD_AGENT_CLIPBOARD_IMAGE_PNG, { image/png, NULL }, }, { VD_AGENT_CLIPBOARD_IMAGE_BMP, { image/bmp, image/x-bmp, image/x-MS-bmp, image/x-win-bitmap, NULL }, }, -- 1.9.3 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [vdagent-linux 1/2] Reply to TIMESTAMP requests
This is to please vncviewer. https://bugzilla.redhat.com/show_bug.cgi?id=1117764 --- src/vdagent-x11-priv.h | 1 + src/vdagent-x11.c | 15 +++ 2 files changed, 16 insertions(+) diff --git a/src/vdagent-x11-priv.h b/src/vdagent-x11-priv.h index c607850..4a5729b 100644 --- a/src/vdagent-x11-priv.h +++ b/src/vdagent-x11-priv.h @@ -83,6 +83,7 @@ struct vdagent_x11 { Atom targets_atom; Atom incr_atom; Atom multiple_atom; +Atom timestamp_atom; Window root_window[MAX_SCREENS]; Window selection_window; struct udscs_connection *vdagentd; diff --git a/src/vdagent-x11.c b/src/vdagent-x11.c index c5d54ac..752b337 100644 --- a/src/vdagent-x11.c +++ b/src/vdagent-x11.c @@ -218,6 +218,7 @@ struct vdagent_x11 *vdagent_x11_create(struct udscs_connection *vdagentd, x11-targets_atom = XInternAtom(x11-display, TARGETS, False); x11-incr_atom = XInternAtom(x11-display, INCR, False); x11-multiple_atom = XInternAtom(x11-display, MULTIPLE, False); +x11-timestamp_atom = XInternAtom(x11-display, TIMESTAMP, False); for(i = 0; i clipboard_format_count; i++) { x11-clipboard_formats[i].type = clipboard_format_templates[i].type; for(j = 0; clipboard_format_templates[i].atom_names[j]; j++) { @@ -1036,6 +1037,20 @@ static void vdagent_x11_handle_selection_request(struct vdagent_x11 *x11) return; } +if (event-xselectionrequest.target == x11-timestamp_atom) { +/* TODO: use more accurate selection time */ +guint32 timestamp = event-xselectionrequest.time; + +XChangeProperty(x11-display, event-xselectionrequest.requestor, + event-xselectionrequest.property, +event-xselectionrequest.target, 32, PropModeReplace, +(guint8*)timestamp, 1); +vdagent_x11_send_selection_notify(x11, + event-xselectionrequest.property, NULL); + return; +} + + if (event-xselectionrequest.target == x11-targets_atom) { vdagent_x11_send_targets(x11, selection, event); return; -- 1.9.3 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] video performance in rhel/centos 7 vs fedora 20
Hi - Original Message - Hi All, We have been piloting deployments of VM using Fedora 20 host and guest and have been very happy with performance and stability in almost every respect, so a big thanks to all for this hard work. Things are looking great. Now we have been testing deployments of these same VMs (F20 guests) on rhel 7 (centos 7). We migrated one over and one of the issues seems to be a severe degradation of video performance vis-a-vis the F20 host. The difference between rhel7 and f20 host is quite surprising. I get quite bad performance with f20 host as well (spice 0.12.4-3, qemu 2.0.0-5) Are your host configured with the same spice settings (in particular streaming-video and other compression settings) ? The setup is a C7 host, F20 guest and either C7 or F20 client, either local to the host or on the LAN. In this setup, the video plays fine for a few seconds, but eventually degrades to about 1fps with severe tearing of the video. Video does remain in sync with audio and there are no audio breakups. Any pointers on things to try? I have been investigating some video rendering issues with rhel7 guest on rhel7 host, see https://bugzilla.redhat.com/show_bug.cgi?id=1030024 However, even with the cogl fix and PutImage BIG-REQUEST, the video regions seems to vary too much for the Spice video filter to perform well (using firefox/html5 video youtube). I believe it will need to be improved. (the cogl fix allows much more accurate region invalidation, the big-request allows to update whole region atomically and not by chunks) I'm willing to rebuild some host components (e.g. spice-server or qemu or whatever) or try some patches or configuration changes to address this to track it down. Your help would be most welcome to investigate and improve this further. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] video performance in rhel/centos 7 vs fedora 20
Greetings, - Original Message - Hi - Original Message - Hi All, We have been piloting deployments of VM using Fedora 20 host and guest and have been very happy with performance and stability in almost every respect, so a big thanks to all for this hard work. Things are looking great. Now we have been testing deployments of these same VMs (F20 guests) on rhel 7 (centos 7). We migrated one over and one of the issues seems to be a severe degradation of video performance vis-a-vis the F20 host. The difference between rhel7 and f20 host is quite surprising. I get quite bad performance with f20 host as well (spice 0.12.4-3, qemu 2.0.0-5) Are your host configured with the same spice settings (in particular streaming-video and other compression settings) ? The setup is a C7 host, F20 guest and either C7 or F20 client, either local to the host or on the LAN. In this setup, the video plays fine for a few seconds, but eventually degrades to about 1fps with severe tearing of the video. Video does remain in sync with audio and there are no audio breakups. Any pointers on things to try? I have been investigating some video rendering issues with rhel7 guest on rhel7 host, see https://bugzilla.redhat.com/show_bug.cgi?id=1030024 However, even with the cogl fix and PutImage BIG-REQUEST, the video regions seems to vary too much for the Spice video filter to perform well (using firefox/html5 video youtube). I believe it will need to be improved. (the cogl fix allows much more accurate region invalidation, the big-request allows to update whole region atomically and not by chunks) I'm willing to rebuild some host components (e.g. spice-server or qemu or whatever) or try some patches or configuration changes to address this to track it down. Your help would be most welcome to investigate and improve this further. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel The original writer said that Fedora 20 was great and RHEL7 sucked... and you said the opposite. Which is correct? Here are the differences between the two: -- RHEL7 -- libvirt-client-1.1.1-29.el7.x86_64 libvirt-daemon-1.1.1-29.el7.x86_64 libvirt-daemon-config-network-1.1.1-29.el7.x86_64 libvirt-daemon-driver-interface-1.1.1-29.el7.x86_64 libvirt-daemon-driver-network-1.1.1-29.el7.x86_64 libvirt-daemon-driver-nodedev-1.1.1-29.el7.x86_64 libvirt-daemon-driver-nwfilter-1.1.1-29.el7.x86_64 libvirt-daemon-driver-qemu-1.1.1-29.el7.x86_64 libvirt-daemon-driver-secret-1.1.1-29.el7.x86_64 libvirt-daemon-driver-storage-1.1.1-29.el7.x86_64 libvirt-daemon-kvm-1.1.1-29.el7.x86_64 libvirt-gconfig-0.1.7-3.el7.x86_64 libvirt-glib-0.1.7-3.el7.x86_64 libvirt-gobject-0.1.7-3.el7.x86_64 libvirt-python-1.1.1-29.el7.x86_64 qemu-kvm-1.5.3-60.el7_0.2.x86_64 qemu-kvm-common-1.5.3-60.el7_0.2.x86_64 spice-glib-0.20-8.el7.x86_64 spice-gtk3-0.20-8.el7.x86_64 spice-server-0.12.4-5.el7.x86_64 spice-vdagent-0.14.0-7.el7.x86_64 -- Fedora 20 -- libvirt-1.1.3.5-2.fc20.x86_64 libvirt-daemon-1.1.3.5-2.fc20.x86_64 libvirt-daemon-config-network-1.1.3.5-2.fc20.x86_64 libvirt-daemon-config-nwfilter-1.1.3.5-2.fc20.x86_64 libvirt-daemon-driver-interface-1.1.3.5-2.fc20.x86_64 libvirt-daemon-driver-libxl-1.1.3.5-2.fc20.x86_64 libvirt-daemon-driver-lxc-1.1.3.5-2.fc20.x86_64 libvirt-daemon-driver-network-1.1.3.5-2.fc20.x86_64 libvirt-daemon-driver-nodedev-1.1.3.5-2.fc20.x86_64 libvirt-daemon-driver-nwfilter-1.1.3.5-2.fc20.x86_64 libvirt-daemon-driver-qemu-1.1.3.5-2.fc20.x86_64 libvirt-daemon-driver-secret-1.1.3.5-2.fc20.x86_64 libvirt-daemon-driver-storage-1.1.3.5-2.fc20.x86_64 libvirt-daemon-driver-uml-1.1.3.5-2.fc20.x86_64 libvirt-daemon-driver-vbox-1.1.3.5-2.fc20.x86_64 libvirt-daemon-driver-xen-1.1.3.5-2.fc20.x86_64 libvirt-daemon-kvm-1.1.3.5-2.fc20.x86_64 libvirt-docs-1.1.3.5-2.fc20.x86_64 libvirt-gconfig-0.1.7-2.fc20.x86_64 libvirt-glib-0.1.7-2.fc20.x86_64 libvirt-gobject-0.1.7-2.fc20.x86_64 libvirt-python-1.1.3.5-2.fc20.x86_64 qemu-kvm-1.6.2-6.fc20.x86_64 spice-glib-0.23-2.fc20.x86_64 spice-gtk-0.23-2.fc20.x86_64 spice-gtk3-0.23-2.fc20.x86_64 spice-gtk-tools-0.23-2.fc20.x86_64 spice-server-0.12.5-2.fc20.x86_64 TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work] ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] video performance in rhel/centos 7 vs fedora 20
On Tue, Jul 15, 2014 at 11:22 PM, Marc-André Lureau mlur...@redhat.com wrote: Hi - Original Message - Hi All, We have been piloting deployments of VM using Fedora 20 host and guest and have been very happy with performance and stability in almost every respect, so a big thanks to all for this hard work. Things are looking great. Now we have been testing deployments of these same VMs (F20 guests) on rhel 7 (centos 7). We migrated one over and one of the issues seems to be a severe degradation of video performance vis-a-vis the F20 host. The difference between rhel7 and f20 host is quite surprising. I get quite bad performance with f20 host as well (spice 0.12.4-3, qemu 2.0.0-5) Hi, I got confused long time ago, actually, the performance between centos and fedora is quite different, as installing win7 guest for example, 10min for centos host, but 1h for fedora host! Maybe the reason is the difference of IO behavior, but I'm not sure. Are your host configured with the same spice settings (in particular streaming-video and other compression settings) ? The setup is a C7 host, F20 guest and either C7 or F20 client, either local to the host or on the LAN. In this setup, the video plays fine for a few seconds, but eventually degrades to about 1fps with severe tearing of the video. Video does remain in sync with audio and there are no audio breakups. Any pointers on things to try? I have been investigating some video rendering issues with rhel7 guest on rhel7 host, see https://bugzilla.redhat.com/show_bug.cgi?id=1030024 However, even with the cogl fix and PutImage BIG-REQUEST, the video regions seems to vary too much for the Spice video filter to perform well (using firefox/html5 video youtube). I believe it will need to be improved. (the cogl fix allows much more accurate region invalidation, the big-request allows to update whole region atomically and not by chunks) I'm willing to rebuild some host components (e.g. spice-server or qemu or whatever) or try some patches or configuration changes to address this to track it down. Your help would be most welcome to investigate and improve this further. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel