[Spice-devel] [PATCH spice-gtk 2/4] main: send only pending monitor config changes
Jonathon Jongsma
jjongsma at redhat.com
Fri Apr 3 09:45:40 PDT 2015
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.
>
> > 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.
More information about the Spice-devel
mailing list