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. > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel