ack
- Original Message -
> When the first display is disabled and the vdagent is restarted in the guest,
> it sometimes becomes enabled. This appears to be caused by a race condition
> when an agent becomes connected. When the agent becomes connected,
> virt-viewer
> triggers a display upd
Make sure we send a xfer data message for 0-size files.
This avoid leaking file descriptiors in guest agent when
copying such files.
https://bugzilla.redhat.com/show_bug.cgi?id=1135099
---
gtk/channel-main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gtk/channel-main.c
When the first display is disabled and the vdagent is restarted in the guest,
it sometimes becomes enabled. This appears to be caused by a race condition
when an agent becomes connected. When the agent becomes connected, virt-viewer
triggers a display update (spice_main_send_monitor_config()). This
Hi
- Original Message -
> > Yes, but what if the reply doesn't come after 5s, we will still get the
> > same bugs I suppose.
>
> If the reply doesn't come after 5s, then we assume that the server is
> old and doesn't support sparse monitor configurations. In this case,
> sending down a no
On Thu, 2014-08-28 at 12:57 -0400, Marc-André Lureau wrote:
>
> - Original Message -
> > > > To solve the issue, we trigger a display update when the agent becomes
> > > > connected, but give it a long timeout (e.g. 5 seconds). This gives some
> > > > time
> > >
> > > To avoid the timeout
- Original Message -
> > > To solve the issue, we trigger a display update when the agent becomes
> > > connected, but give it a long timeout (e.g. 5 seconds). This gives some
> > > time
> >
> > To avoid the timeout, we could rely on the agent caps reply to happen
> > right after sending
On Thu, 2014-08-28 at 11:59 -0400, Marc-André Lureau wrote:
>
> - Original Message -
> > When the first display is disabled and the vdagent is restarted in the
> > guest,
> > it sometimes becomes enabled. This appears to be caused by a race condition
> > when an agent becomes connected. W
- Original Message -
> When the first display is disabled and the vdagent is restarted in the guest,
> it sometimes becomes enabled. This appears to be caused by a race condition
> when an agent becomes connected. When the agent becomes connected,
> virt-viewer
> triggers a display update
When the first display is disabled and the vdagent is restarted in the guest,
it sometimes becomes enabled. This appears to be caused by a race condition
when an agent becomes connected. When the agent becomes connected, virt-viewer
triggers a display update (spice_main_send_monitor_config()). This
looks good to me, ack
- Original Message -
> Once transferring multiple files is supported, do not bother the user
> opening the file transfer directory for each file transferred, just do it
> when the last file transfer is finished.
> ---
> src/vdagent-file-xfers.c | 3 ++-
> 1 file chan
Once transferring multiple files is supported, do not bother the user
opening the file transfer directory for each file transferred, just do it
when the last file transfer is finished.
---
src/vdagent-file-xfers.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/vdagent-fi
ping
this patch solves the assert from bug
https://bugzilla.redhat.com/show_bug.cgi?id=1058625
On Mon, Nov 18, 2013 at 11:28 AM, Marc-André Lureau <
marcandre.lur...@gmail.com> wrote:
> In reds_send_link_ack(), lookup the channel with the same id as the link
> message.
> ---
> server/reds.c |
looks fine, ack
- Original Message -
> Allow to drag and drop, from host to guest, more than one file at the
> same time.
> ---
> gtk/channel-main.c | 53
> ++---
> 1 file changed, 26 insertions(+), 27 deletions(-)
>
> diff --git a/gtk/cha
Allow to drag and drop, from host to guest, more than one file at the
same time.
---
gtk/channel-main.c | 53 ++---
1 file changed, 26 insertions(+), 27 deletions(-)
diff --git a/gtk/channel-main.c b/gtk/channel-main.c
index f33b0fd..165f51b 100644
14 matches
Mail list logo
