Hi,
On Tue, Feb 07, 2017 at 11:41:05AM +0100, Pavel Grunt wrote:
> On Mon, 2017-02-06 at 12:06 +0100, Victor Toso wrote:
> > From: Victor Toso
> >
> > [0] SPICE_MSGC_DISPLAY_PREFERRED_VIDEO_CODEC_TYPE
> >
> > This message provides a list of video codecs based on client's order
> > of preference
Hi,
On Wed, Feb 08, 2017 at 06:55:14PM +0100, Christophe de Dinechin wrote:
>
> > On 31 Jan 2017, at 12:08, Victor Toso wrote:
> >
> > +#define SPICY_UNGRAB_INFO "Use %s to ungrab mouse”
>
> Shouldn’t that be
>
> #define SPICY_UNGRAB_INFO _(“Use %s to ungrab mouse”)
Maybe? I'd argue that sp
Hi,
On Wed, Feb 08, 2017 at 11:41:55AM -0600, Jonathon Jongsma wrote:
> On Tue, 2017-01-31 at 12:08 +0100, Victor Toso wrote:
> > From: Victor Toso
> >
> > ---
> > tools/spicy.c | 19 ---
> > 1 file changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/tools/spicy.c b/
Acked-by: Jonathon Jongsma
On Tue, 2017-02-07 at 11:59 +0100, Christophe Fergeau wrote:
> Minor refactoring in preparation for the next commits (and regardless
> of
> the other commits, the less variables to keep track of when reading
> code, the better).
> ---
> server/red-channel-client.c | 7
On Tue, 2017-02-07 at 11:59 +0100, Christophe Fergeau wrote:
> This commit removes IncomingHandlerInterface::on_error and
> IncomingHandlerInterface::on_input. As with previous commits, these
> vfuncs are always calling the method, and RedChannel::init sets them
> to
> point to RedChannelClient met
On Tue, 2017-02-07 at 11:59 +0100, Christophe Fergeau wrote:
> RedChannel uses OutgoingHandlerInterface to provide constant pointers
> to
> RedChannelClient methods. This OutgoingHandlerInterface structure is
> then used in RedChannelClient to indirectly call these methods.
>
> Since the content o
On Tue, 2017-02-07 at 11:59 +0100, Christophe Fergeau wrote:
> Similarly to the previous commits, this removes an indirection level,
> IncomingHandlerInterface stores pointers to
> alloc_recv_buf/release_recv_buf vfuncs, but these are always set to
> RedChannel::alloc_recv_buf/RedChannel::release_r
On Tue, 2017-02-07 at 11:59 +0100, Christophe Fergeau wrote:
> Have the RedChannelClient callback call into a RedChannel callback
> rather than doing the opposite. This will be useful in some
> subsequent
> refactoring of this code.
> ---
> server/red-channel-client.c | 2 ++
> server/red-channel.
On Tue, 2017-02-07 at 11:59 +0100, Christophe Fergeau wrote:
> It was probably meant to be used as a "user_data" argument for the
> various callbacks, but turns out not to be used.
Hmm, it looks like the last use of this 'data' variable was removed in
96e94c6f. That commit used g_object_set_data()
> On 31 Jan 2017, at 12:08, Victor Toso wrote:
>
> +#define SPICY_UNGRAB_INFO "Use %s to ungrab mouse”
Shouldn’t that be
#define SPICY_UNGRAB_INFO_(“Use %s to ungrab mouse”)
> +g_string_append_printf(status, "\t"SPICY_UNGRAB_INFO, seq);
Just curious, why do you split the \t
On Tue, 2017-01-31 at 12:08 +0100, Victor Toso wrote:
> From: Victor Toso
>
> ---
> tools/spicy.c | 19 ---
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/tools/spicy.c b/tools/spicy.c
> index bffbef8..4712db6 100644
> --- a/tools/spicy.c
> +++ b/tools/spicy
On Wed, Feb 08, 2017 at 06:34:47PM +0200, Yuri Benditovich wrote:
> I've prepared the patch for QEMU and the patch was discussed with Gerd
> Hoffman. He has similar fix in queue, not merged yet, so there is no need
> to submit patch for QEMU, existing one will be merged
Ah thanks, I did not realiz
I've prepared the patch for QEMU and the patch was discussed with Gerd
Hoffman. He has similar fix in queue, not merged yet, so there is no need
to submit patch for QEMU, existing one will be merged
On Wed, Feb 8, 2017 at 1:18 PM, Christophe Fergeau
wrote:
> On Tue, Feb 07, 2017 at 12:29:23AM +0
When running 'remote-viewer' without arguments,
and selecting a non-supported protocol, e.g. ssh://foo,
the generated error was silently swallowed by the retry loop.
This was introduced in 06b2c382468876a19600374bd59475e66d488af8.
---
src/remote-viewer.c | 3 +++
1 file changed, 3 insertions(+)
d
---
scripts/Xspice | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/Xspice b/scripts/Xspice
index 30d10fa..41fd80c 100755
--- a/scripts/Xspice
+++ b/scripts/Xspice
@@ -211,7 +211,7 @@ signal.signal(signal.SIGTERM, cleanup)
atexit.register(cleanup)
if args.auto:
-
With python3, without universal_newlines=True, Popen().stdout.read()
will return a byte array, while find(str) expects to operate on a
string.
I've checked that this still works with python2 as well.
---
scripts/Xspice | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/Xsp
On Wed, Feb 08, 2017 at 01:00:00PM +, Frediano Ziglio wrote:
> read_binary attach mem to allocated list.
read_binary() attaches 'mem' to the SpiceReplay::allocated list
> On failure all memory attached to allocated list are freed
On failure, SpiceReplay::allocated and its content are freed b
On Sat, Feb 04, 2017 at 11:55:48PM +0200, Jordan Sokolic wrote:
> Hello all,
>
> I've recently begun using Xspice as a remote desktop solution. I'm
> finding its performance to be greatly superior to VNC, RDP or others.
> Nice!
> I wrote a small wrapper script that launches Xspice on a remote
> ma
On Wed, Feb 08, 2017 at 02:38:04PM +0100, Pavel Grunt wrote:
> On Wed, 2017-02-08 at 11:42 +0100, Christophe Fergeau wrote:
> > On Wed, Feb 08, 2017 at 10:57:42AM +0100, Pavel Grunt wrote:
> > > On Mon, 2017-02-06 at 18:15 +0100, Christophe Fergeau wrote:
> > > > Using spice_info() gets in the way
Ack!
thanks,
Pavel
On Wed, 2017-02-08 at 15:31 +0100, Christophe Fergeau wrote:
> This allows Xspice to run when using python3 instead of python2
> ---
> scripts/Xspice | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/scripts/Xspice b/scripts/Xspice
> in
This allows Xspice to run when using python3 instead of python2
---
scripts/Xspice | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/scripts/Xspice b/scripts/Xspice
index ada99d1..30d10fa 100755
--- a/scripts/Xspice
+++ b/scripts/Xspice
@@ -34,7 +34,7 @@ def whic
On Wed, 2017-02-08 at 11:42 +0100, Christophe Fergeau wrote:
> On Wed, Feb 08, 2017 at 10:57:42AM +0100, Pavel Grunt wrote:
> > On Mon, 2017-02-06 at 18:15 +0100, Christophe Fergeau wrote:
> > > Using spice_info() gets in the way of tests
> >
> > I would say that is the problem of the test, it is
read_binary attach mem to allocated list.
On failure all memory attached to allocated list are freed
but also replay->primary_mem is freed causing the double free.
Note that this double free can happen only on currupted
or wrong record images.
Signed-off-by: Frediano Ziglio
---
server/red-replay
On Tue, Feb 07, 2017 at 12:29:23AM +0200, Yuri Benditovich wrote:
> The driver uses fallback mode when it does not receive
> startup display information from the OS. This change
> allows solution for https://bugzilla.redhat.com/show_bug.cgi?id=1417448
> without fix in qemu for video mode switch fro
On Wed, Feb 08, 2017 at 10:50:52AM +0100, Pavel Grunt wrote:
> On Mon, 2017-02-06 at 18:15 +0100, Christophe Fergeau wrote:
> > Currently, the network sockets opened by reds_init_net() are not
> > closed
> > on destruction, in other words they are leaked.
>
> Acked-by: Pavel Grunt
>
> > ---
> >
On Wed, Feb 08, 2017 at 10:57:42AM +0100, Pavel Grunt wrote:
> On Mon, 2017-02-06 at 18:15 +0100, Christophe Fergeau wrote:
> > Using spice_info() gets in the way of tests
>
> I would say that is the problem of the test, it is possible to check
> the INFO level as well. imo spice_info messages are
On Wed, 2017-02-08 at 10:50 +0100, Victor Toso wrote:
> From: Victor Toso
>
> Similar to preferred video compression, a radio button showing
> mjpeg,
> vp8, vp9 and h264 in case server has the proper [0] capability
>
> [0] SPICE_DISPLAY_CAP_PREF_VIDEO_CODEC_TYPE
>
> Signed-off-by: Victor Toso
On Mon, 2017-02-06 at 18:15 +0100, Christophe Fergeau wrote:
> Using spice_info() gets in the way of tests
I would say that is the problem of the test, it is possible to check
the INFO level as well. imo spice_info messages are useful
Pavel
> using
> g_test_expect_message() as all the messages
From: Victor Toso
Similar to preferred video compression, a radio button showing mjpeg,
vp8, vp9 and h264 in case server has the proper [0] capability
[0] SPICE_DISPLAY_CAP_PREF_VIDEO_CODEC_TYPE
Signed-off-by: Victor Toso
---
tools/spicy.c | 47 +++
On Mon, 2017-02-06 at 18:15 +0100, Christophe Fergeau wrote:
> Currently, the network sockets opened by reds_init_net() are not
> closed
> on destruction, in other words they are leaked.
Acked-by: Pavel Grunt
> ---
> server/reds.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff
Hi,
On Mon, Feb 06, 2017 at 06:32:21PM +0100, Pavel Grunt wrote:
> On Mon, 2017-02-06 at 17:52 +0100, Pavel Grunt wrote:
> > On Mon, 2017-02-06 at 12:06 +0100, Victor Toso wrote:
> > > From: Victor Toso
> > >
> > > Similar to preferred video compression, a radio button showing
> > > mjpeg,
> > >
On Wed, 2017-02-08 at 10:26 +0100, Victor Toso wrote:
> Hi,
>
> On Wed, Feb 08, 2017 at 10:25:10AM +0100, Victor Toso wrote:
> > From: Victor Toso
> >
> > Using g_hash_table_iter_init() and g_hash_table_iter_next() here
> > is
> > bad as spice_file_transfer_task_completed() will emit "finished"
Hi,
On Wed, Feb 08, 2017 at 10:25:10AM +0100, Victor Toso wrote:
> From: Victor Toso
>
> Using g_hash_table_iter_init() and g_hash_table_iter_next() here is
> bad as spice_file_transfer_task_completed() will emit "finished"
> signal from SpiceFileTransferTask resulting in the original GHashTable
From: Victor Toso
Using g_hash_table_iter_init() and g_hash_table_iter_next() here is
bad as spice_file_transfer_task_completed() will emit "finished"
signal from SpiceFileTransferTask resulting in the original GHashTable
to be changed in file_transfer_operation_task_finished()
Debug will show:
34 matches
Mail list logo
