[Spice-devel] [PATCH spice-gtk 2/4] main: send only pending monitor config changes

[Jonathon Jongsma]

On Fri, 2015-04-03 at 11:45 -0500, Jonathon Jongsma wrote:
> On Fri, 2015-04-03 at 12:44 -0400, Marc-André Lureau wrote:
> > Hi
> > 
> > ----- Original Message -----
> > > On Fri, 2015-04-03 at 11:25 -0400, Marc-André Lureau wrote:
> > > Oh, I just thought of one potential example (note that I haven't
> > > actually tested it with your patches):
> > > 
> > > - User connects a fullscreen (1600x900) virt-viewer to a guest
> > > - user reboots guest
> > > - during reboot, guest switches to e.g. 720x400 (which results in a
> > > scaled display widget in the fullscreen window)
> > > - There is no vdagent running during boot
> > > - The graphical login screen (gdm) comes up and vdagent connects
> > > - the gdm greeter will default to e.g. 1024x768
> > > - There are no pending monitor changes, so your patch prevents us from
> > > sending a monitors config message to the server
> > > 
> > > Result: the gdm greeter is a 1024x768 widget scaled up to a fullscreen
> > > 1600x900 window. In other words, it is zoomed in, "fuzzy", and with
> > > black bars along the sides.
> > > 
> > > Previously, we would have unconditionally sent a monitors config update
> > > to the server when the vdagent became connected, which would have
> > > resulted in the gdm screen being configured to the fullscreen window
> > > size.
> > 
> > If auto-resize is disabled, we shouldn't send monitor config messages: this is a bug we have currently.
> > 
> > If it's enabled, this patch shouldn't break current behaviour.
> 
> I just gave you an example where it broke current behavior.

It also apparently breaks monitor configuration on windows guests. I get
the following when first trying to resize a monitor after starting
virt-viewer with a 2-monitor windows guest:

(virt-viewer:7800): GSpice-DEBUG: ../../gtk/channel-main.c:1307 Not
sending monitors config, missing monitors


> 
> > 
> > > This is just one example off the top of my head, but I'm sure there are
> > > several other scenarios that I can't think of immediately (VT switching?
> > > vdagent restarting?).
> > > 
> > > As I said in my previous email, I think that if we change this behavior,
> > > it would probably be better to remove it completely and leave it up to
> > > the application to handle.
> > 
> > This is not possible unless you implement the behaviour in all existing applications. What you want is a way to prevent sending those unwanted configuration messages, which is what these series help with.
>