On Wed, 2015-04-01 at 18:02 +0200, Marc-André Lureau wrote: > > On Wed, Apr 1, 2015 at 5:41 PM, Jonathon Jongsma <jjongsma@xxxxxxxxxx> > wrote: > This is a potential solution to the bug described in > https://bugzilla.redhat.com/show_bug.cgi?id=1200750. It seems > to fix the > problem, but if anybody has a suggestion for a more elegant > solution, I'd be > happy to hear about it. > > > > Is the issue related to the client reconfiguring the window monitors > on startup after initial server MonitorConfig and sending back that > old configuration? If so, is it possible to investigate how to filter > the resize triggered by the application itself as opposed to resize by > user? (I would consider the timer hack as the last possibility) What seems to happen is the following: (assume that the guest currently has 2 displays enabled, and the client machine has 1 monitor) - client connects to server, main channel / vdagent connects - client sends monitors-config message to server to set displays to the same resolution as fullscreen local display (e.g. display #0 = 1600x900) - server receives monitors-config messages and forwards it to guest vdagent to handle - Display channel gets connected, and server sends current monitor configuration to the client (e.g. display #0 = 1024x768, display #1=800x600) - client creates two windows in response to the message from the server - the updated monitors-config message arrives from the server, and display #0 gets resized to 1600x900 and display #1 gets disabled. - Because display #0 gets resized, it triggers the client to send down a new monitors config message, but due to https://bugzilla.redhat.com/show_bug.cgi?id=868970, the second display also gets re-enabled. In general this is an area that's tricky to get right. We recently added some code to try to avoid sending down monitor-config messages from the client when they're not necessary (e.g. when they would be set to the same dimensions that it already is). But that already created a couple of minor regressions, so I'm a little bit reluctant to do too much more there. Jonathon _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel