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
